Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Blizzard

Pages: [1] 2 3 ... 40
5
New Projects / MOVED: A Maiden's Ballad
« on: July 12, 2018, 10:03:57 AM »

6
News / Suggestions / Feedback / HTTPS and SSL
« on: April 15, 2018, 06:16:15 PM »
The forum has been reconfigured to require an SSL connection over HTTP (also known as HTTPS) in order to improve security. Everything should work as before, but if you have issues, let me know.

7
RMMV Script Database / [MV] Ultra Mode 7
« on: April 15, 2018, 02:23:32 PM »
Ultra Mode 7
Authors: Blizzard
Version: 1.3.7
Type: 3D tilemap rendering
Key Term: Environment Add-on

Introduction

Ultra Mode 7 simulates the Mode 7 rendering mode from the SNES by using 3D rendering (hence the "Ultra"). Sprites are scaled appropriately and use additional code to determine whether they are visible, because of cut-off distance. The view of a Mode 7 map is defined by the following parameters:

  • camera distance
  • field of view
  • pitch rotation angle
  • yaw rotation angle
  • maximum Z coordinate

This work is protected by the following license:
Quote
Creative Commons - Attribution-NonCommercial-ShareAlike 3.0 Unported
( http://creativecommons.org/licenses/by-nc-sa/3.0/ )

You are free:

to Share - to copy, distribute and transmit the work
to Remix - to adapt the work

Under the following conditions:

Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Noncommercial. You may not use this work for commercial purposes.

Share alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

- For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page.

- Any of the above conditions can be waived if you get permission from the copyright holder.

- Nothing in this license impairs or restricts the author's moral rights.

Features

  • render map in 3D
  • control rendering with various parameters and even change them on the fly
  • supports white fading of horizon
  • supports auto-scaling for sprites depending on distance from camera
  • high performance
  • easy to use

v1.1.0
  • added animation function for parameters
  • renamed RENDER_PIXELATED option to TILEMAP_PIXELATED
  • added CHARACTERS_PIXELATED option
  • fixed issue with floating characters
  • fixed issue with normal maps not working anymore
  • added some code to prevent compatibility issues with some map scripts

v1.2.0
  • fixed FPS drop problem while moving

v1.2.1
  • fixed save data issue

v1.2.2
  • fixed a syntax error that was caused by code cleanup

v1.2.3
  • added parallax distance parameter in maps for parallax movement with yaw and pitch
  • renamed "Camera" functions to "CameraDistance"
  • fixed bug with parallax scrolling on non-Mode 7 maps
  • fixed bug with shaking the screen
  • removed FOV limit and implemented orthogonal projection with FOV of 0°

v1.2.4
  • fixed accidental removal of animateCameraDistance function

v1.3.0
  • implemented map looping functionality
  • added workaround for PIXI bug where a lag spike would occur about every 10 seconds
  • fixed issue where sprite direction didn't display properly at certain yaw angles
  • fixed issue where movement controls didn't adjust to yaw angle
  • added CHARACTERS_ADJUST_SPRITE_DIRECTION option
  • fixed coordinate offset when using yaw angle

v1.3.1
  • fixed a crash with event testing

v1.3.2
  • added coordinate rounding for X and Y coordinates
  • improved code that handles sprite visibility when outside of the view frustum
  • removed some leftover debug prints

v1.3.3
  • fixed issue with event visibility on map borders when using looping maps

v1.3.4
  • added compatibility code for KhasUltraLighting
  • added compatibility instructions for Terrax Plugins - Lighting system

v1.3.5
  • corrected some minor positioning and scaling calculation errors
  • improved compatibility code for KhasUltraLighting

v1.3.6
  • added experimental compatibility for BattleLighting plugin

v1.3.7
  • added experimental compatibility for BattleLighting plugin

Screenshots

(click to show/hide)
(click to show/hide)
https://i.gyazo.com/9c7d3250509a967665e978ea608f46af

Demo

Ultra Mode 7 Demo

Script

Script Download

Instructions

Inside the script in the first comment.

Compatibility
  • Requires WebGL. Does not work with canvas and due to how canvas works, it can never support canvas.
  • Because the tilemap is rendered entirely flat, tile priority isn't used.
  • Scaling has been optimized for usage of an FOV of 60°. Using different values will cause some weird scales being used for characters.
  • Due to yaw rotation requiring turning of characters, 8-directional characters sprites might have only limited support.

Credits and Thanks

  • Blizzard

Author's Notes

Make sure to read the instructions and study the demo before asking questions.

If you find any bugs, please report them here:
http://forum.chaos-project.com

That's it! N-Joy! =D

8
New Projects / MOVED: Rave Heart (Demo available)
« on: February 22, 2018, 09:58:16 AM »

9
New Projects / MOVED: Elf's Dairy (Completed)
« on: February 22, 2018, 09:57:05 AM »

10
Lexima Legends - Ancient War / What is this?
« on: January 12, 2018, 11:08:11 PM »
Since it appears that I will enlist some help for this game, I decided that the best way to handle all this is to use the obvious tool I have at my disposal: The forum.

For those who don't know yet: I am working on a new Lexima Legends title and I'm using RPG Maker MV. This game will be commercial and I will most likely be paying for some external helpers. My plan is a release on Steam, Google Play and iTunes App Store. Since my budget is limited, I might even try a Kickstarter (but don't count on it).



The game's premise is simple and takes place long before anything of the original trilogy happened:

The Chaos Wielder Regulus has obtained massive power through unknown means and commands an army to take the planet the player grew up on. Leximus and Rivy get involved in the conflict. The player is misled to believe they fight for a rebellion against an unjust system, but in reality they serve Regulus. After joining Leximus and Rivy, the player discovers that the rebellion is a setup. Leximus tasks the player with defeating a battalion while he investigates.



The game will play somewhat similar to Ogre Battle: March of the Black Queen and Ogre Battle 64: Person of Lordly Calibur. The game takes place on a huge map RTS-style. Once two units are close enough, they engage into RPG-style turn-based battle which is automated. The loser retreats (depending on a battle score system). Standard terrain and weather affects units and characters.

On top of these base mechanics there will be additional mechanics such as Soul Rage abilities that can be used during battles to manipulate the outcome. Players will face many choices and decisions which will affect the missions they play, they story they experience and the ending they get. The plan is about 40 missions with 3 different paths, altogether about 100 missions to play.



Some interesting features include a lot of custom scripts, barely anything resembling the originals and probably most prominently: Mode 7!

11
Chat / Quick Start Guide to Cryptocurrencies
« on: December 19, 2017, 08:28:00 PM »
So, I've been doing some stuff with cryptocurrencies for the past 6 months and I decided it would be a nice idea to share some of my experiences. But first 2 disclaimers:



1. This is not financial advice. It is merely my opinion and experience so far. You are responsible for any trading you decide to do, regardless of the outcome.

2. Cryptocurrency trading is highly volatile and very risky. There is a realistic chance that you will lose all your investment.




Blockchain technology

Before I go into any detail, I want to explain what a blockchain is. It's basically a huge log file with the history of all transactions. What miners actually do is solve mathematical puzzles (with a hashing algorithm) in order to confirm the legitimacy of these transactions and then they are reward with a certain amount Bitcoins for their work. You also put aside some of the currency you send that is then awarded to the miner as well which basically means you pay a fee for transactions (you will see soon why this is important). This is also why it's called "proof of work algorithm" since it's assumed that you did the work to solve the puzzles if you have the solution. The key here is that miners all have copies of the entire blockchain (which is currently 170GB I think) and they sync each other up all the time so it's not really possible to do something like a 51%-attack to confirm fake transactions, because other miners will not confirm them if you try to fake it.



Mining

The two most important currencies are the well-known Bitcoin (XBT/BTC) and Ether (ETH). About 5-6 months ago 2 friends and I decided to take up Ether mining. So far it has paid off the 2 rigs (5 ATI RX580 8GB on each), but mainly due to the massive price surge of Ether. When we started, the price was slightly under $300. Mining is a bit less risky probably since you do have some sort of value in the PCs you put together. If nothing else, you can sell the GPUs for a decent price. Though right now the GPU prices have spiked due to mining demand. We literally got the last 10 GPUs in the entire city at a normal price back in July. Bitcoin mining is useless, because you need ASICs which is basically dedicate hardware and it's very expensive. It's true that one unit can do the work of 5-6 GPUs easily, but it's not worth it. It's too late to take up Bitcoin mining.



Trading / Investing

Now comes the fun part. First I want to suggest a simple rule to follow: Only invest what you are prepare to lose. Never invest any money that you need for living or eating or paying your rent. And please, for the love of god / science / flying spaghetti monster / whatever you believe in, do not, and I repeat DO NOT take out a loan to buy Bitcoin or any other cryptocurrency. This is all very risky and could fuck up your life.

What kind of risk am I taking? Due to my current financial situation, I could probably save money for the next 10 years and buy an apartment without having to take out a loan. Now, with Bitcoin and other currencies I am attempting to invest savings from (I guess) 8 months in order to cut down the entire process to 2 years or even less. If I lose all my money, I lose 8 months which is very little compared to the 10 years I would conventionally need to save up money. But if it succeeds, I might cut down 80%-90% of the time, down to 1-2 years only. This calculated risk for me is acceptable as the potential gain outweighs the risk of losing everything. Of course, this is my personal situation. You need to decide for yourself. My simplest advice is that you take some spare money you have and put it into Ether (ETH). Keep reading for more info on that.

Bitcoin (XBT/BTC)

As of writing Bitcoin spiked at over $20,000 and is currently dancing above the $18,000 limit. Bitcoin is problematic due to many reasons. Since it's the most known cryptocurrency, people will immediately think of Bitcoin when you mention digital currencies. This kind of hype usually pumps up the price as more people buy Bitcoin. The problem is that Bitcoin is highly unpractical as currency. It should rather be viewed as an asset or as investment. And as with all assets and investments, the value can go up and like crazy. I've seen drops of 20% and then recovery by 10%-15% within a single day. It's definitely not for the faint of heart. Another problem with Bitcoin are the transfer fees. 2-3 weeks ago fees were usually at the $10 mark, but now I've seen people post fees like $28 on Twitter. Since the value is pumped right now, it will go down quite a bit at some point. It's hard to say when. Maybe next week, maybe next month, maybe in the next hour. But since it's so well known, Bitcoin's price will go up again after a while. This kind of ups and downs have been happening over its entire history in the past years and each cycle left more people in the user base that actually do believe that Bitcoin is the future. Fun thing is that Bitcoin is lagging behind heavily as far as technology goes which you can already see from the high fees. The transaction times are also very high right now, mostly due to increased demand. Remember this part, it will be important later.

Ether (ETH)

Ether is much better than Bitcoin. Why? Disregarding the low fees and transaction times in comparison, the Ethererum blockchain actually has something called "Smart Contracts". Those are basically small programs and applications that are integrated into the blockchain directly, usually in form of conditional behavior. e.g. You can create a website that automatically sends a confirmation email on purchase from a website. The beauty here is that it's all within the blockchain and nobody can hack your website to mess you up. Because of this single distinction, I think that the Ethereum blockchain is superior and will surpass Bitcoin at some point in the future in price. Whether Bitcoin will crash down or whether Ether will rise to Bitcoin levels, I do not know. Either way, ETH is a good investment IMO.

Bitcoin Cash (BCC/BCH), Litecoin (LTC), Dash (DASH), Ripple (XRP), Monero

These are all so-called alt-coins which have seen quite some boosts in the past months. As far as I can tell, people who are losing their faith, usually turn to these coins. Most of them solve the issue of high transaction fees and long transactions times, but I'm unsure how they would really handle the same load that BTC has right now since a lot more people are trading BTC than they are with the other currencies. It's hard to say. All of these will probably grow as Bitcoin grows, but they all use outdated tech and their scalability issues will catch up to them most likely.

Tronix Token (TRX)

Eh, this is an obscure one. I've started investing a bit of money into it recently since it's very cheap right now (only $0.04 per coin) and it has some potential for growth as it's supposed to help something with content creators, blablabla, didn't listen too much. It's an experiment that has already paid of (I bought some at $0.03). Honestly, you can just ignore it if you're not interested into going deeper. I'm just listing it, because I put some money into it.

Cardano (ADA)

This is another somewhat obscure one. The only reason why I invested in it is because it seems to be more advanced than ETH, but the idea behind it is similar. There's also the interesting fact that it was created to fulfill a vision rather than a functionality and high-profile scientist groups are working on it. Also feel free to ignore it if you're not going any deeper. I don't think it will boom within the next 6 months.

IOTA

I saved the best for last. If any "digital currency" has the potential to actually be used globally within a few years, it's IOTA. It actually doesn't use a blockchain for transactions, but something else entirely called "Tangle". Look it up if you're interested further, but I can tell you right now, this is the only currency that not only doesn't clutter and get slower the more people use it, it gets faster! I'm not shitting you, the math behind it checks out. The idea is basically that each new transaction added into the system requires to confirm two previous transactions. That way the more devices join in, the faster the network gets. This also means no transaction fees at all. And I said "devices" on purpose since the idea is that the simplest IOT devices could handle these kind of transactions so each device would kind of become a consumer and miner at the same time. One possible application of this technology could be autonomous self-driving cars. The car would charge you some IOTA for getting you to your destination and then use the currency to pay for gas and maintenance. They don't have a contract with Microsoft, as was falsely reported recently, but they do work together with them and some other high-profile companies to come up with possible usages and implementations of the whole thing. The only drawback is that it requires a critical mass of users to be able to become fully self-sustained so it might be a miss in the end. Either way, I'm convinced that IOTA will be the world's first widely adopted real digital currency. If not IOTA, then something that tops it.



To sum things up, most of these currencies are probably already in the top 20 as far as market cap goes. I think TRX is the only that's not. If you think of all this as long term investment, the only thing that might be shaky is Bitcoin. Though some believe that Bitcoin will become the new digital gold, mostly due to its high adoption rate so far. Technically it's possible since I don't think the miners that are currently holding the majority of hashing power will easily give up their millions and billions of Dollars. There will always be people supporting it. The question is only when it will stabilize and whether it will fall before that. IMO Bitcoin won't experience as big boosts as other currencies anymore. I'm talking about stuff like 80% (LTC the other day) or 1300% in a month (IOTA) or something like that.

A few last advices I can give you:

1. Don't buy high. Buy when the price drops. You can't predict an increase in price, but if it's already going up, the chances are high that it's too late and the price will come down again. Of course this isn't a rule, but be aware of the risks.

2. Best you just buy some coins and forget about it for 1-2 or 5 years.

3. Don't think in terms of coins, think in terms of your fiat currency. Don't think "I can't buy one Bitcoin, it's too expensive", think "I will invest $1000 into Bitcoin". This makes things much, much simpler.

4. If you want to invest into alt-coins, DO RESEARCH! Don't invest in stuff you don't believe in. e.g. There's this coin called Potcoin. It has something to do with marihuana and payment, but I don't see it go mainstream or have any growth potential or any kind of value besides being a currency so I don't want to invest in it. In comparison to that, IOTA might also be only a currency, but it has the potential to change the world.

5. If anything, put some money into ETH and some into IOTA (50-50 or 60-40 or something like that). Those two have a future. I think that IOTA will go up somewhere during 2018. They are in their beta phase after all.

12
New Projects / MOVED: [XP]Monstructs: Makers and Mayhem
« on: December 15, 2017, 09:50:18 PM »

13
General Discussion / Image upscaling
« on: November 09, 2017, 10:54:53 AM »
FINALLY! A good solution for upscaling images!

https://letsenhance.io/

CP 2.0 HD coming! :D

14
RPG Maker Scripts / MV Mode 7
« on: November 08, 2017, 08:46:11 AM »
Some may already know that I started working on a new game in RMMV. It was all shakey until I wrote my first lines of code. xD I am definitely going to continue working on it and I will release some of my scripts to the public. The one most notable would be a Mode 7 script. Now, I'm wondering what kind of extra features you would like to see in this script, what kind of parameters, what kind of configurations.

15
New Projects / MOVED: Legends of Astravia
« on: November 07, 2017, 08:59:52 AM »

16
Lexima Legends - Chaos Project / Chaos Project 2.0.0 BETA
« on: September 02, 2017, 10:01:53 PM »
The time has come. It's a few days short of 6 years since I started working on this. Initially I wanted to add 2-3 additional hours of gameplay with the "Beyond Epic" game mode, but it kinda mutated into 5 hours. I wanted to make it story-driven and glue the gameplay onto it. That didn't happen. Instead they grew together. I added even some other things like 60-FPS support through XPAce, fixed a lot of minor bugs, rebalanced some minigames and the entire monster arena, added more game modes etc. The normal game experience remains mostly unchanged with the exception of some special tweaks (and 60 FPS obviously), but the additional content will blow your mind.

You might be thinking "Blizzard, you ass, you've been promising this thing now for almost 6 years. It's never going to be done." Well, that's just it. The open beta release date is tomorrow. No, this is not a joke. No, this is not a shitty estimation. I literally have to do one more thing for the game to be a beta version: Finish balancing the final boss fight in the "Beyond Epic" game mode. That's a few hours of work. Sure, there are a few bugs around that I'm aware of, but they are mostly graphical. So besides the boss balancing there's nothing else to be done for the beta.



So, 2.0.0.0. what's new then?

Beyond Epic game mode

  • the ultimate post-game challenge
  • Rivy joins your party to kick some ass
  • max level 1000 with insane stats and no grinding necessary (which doesn't mean you can't grind if you want)
  • new awesome Meta States, play the game like never before
  • beyond epic damage, beyond epic battles, beyond epic music, beyond epic bosses
  • an unexpected closure to the canon storyline
  • unlocked by beating the game in any mode and getting the "good" ending
  • about 5 additional hours of gameplay!

Zero Hero game mode

  • a low-level challenge for those who can handle it
  • enemies drop double gold, but only bosses give EXP

Soul Rage game mode

  • a special challenge for those deeply familiar with the game mechanics
  • normal abilities are not available
  • SR costs are halved
  • Meta Limit costs only 50% SR
  • enemies drop double gold

running at 60 FPS

  • smooth animation with improved engine
  • more custom optimizations to provide an even smoother experience
  • 50% increased movement speed, no more slugging around

supporting XBox 360 compatible controllers for input

  • no more keyboard-jockeying if you want the full old-school experience

all-new Revive Charm accessory in many item shops

  • provides a one-time Auto-Revive until it's used up

improved pet monster battles

  • higher chance to increase stats during battle
  • higher stat increases during battle
  • higher chance to gain stat boosts during battle
  • lower chance to lose stat boosts during battle when hit
  • high stater increases with the items
  • less grind, more fun

more battle BGMs

  • added a new default battle BGM (and left the old one as well)
  • the rest are available automatically in any game mode except "New Game"

improved font installation

  • no more missing text
  • no more hassle installing fonts

new boss-dying animation

  • more unique and fancier than ever

better audio

  • updated a lot of tracks with higher quality audio

changed Mandora Prison

  • for each completed room, you get a reward
  • you can skip rooms
  • reduced difficulty to match the 60 FPS glory

minor bug fixes and improvements

  • graphics
  • dialogs
  • audio timing
  • brand new battle transition
  • improved battle status display
  • game now saves and loads faster
  • added more save points throughout the game to allow for shorter play sessions
  • changed how some skills and enemies work

reworked some dialogue and plot points

  • now Endout is a bit better fleshed out in the earlier story segments

more fun with game modes

  • beating "New Game" will now unlock "And Again!", "Warrior", "Zero Hero" and "Soul Rage" all at once
  • beating "Warrior" or "Zero Hero" will unlock Exerion
  • with so much more new mode craziness going on, the number of save slots is now 12

18
Sea of Code / Randomness and distribution
« on: June 14, 2017, 08:06:33 PM »
Those of you who worked with C or C++ probably know that on Win32 systems that the macro RAND_MAX is only 32,767 (0x7FFF). This causes problems if you want random values higher than that since due to the distribution, there are values that you will never get.

e.g. You want 1,000,000. 1,000,000 / 32,767 ~= 30.52. That means that you can get a 0 or a 31, but never anything between these two numbers.

Now, you could take two numbers and sum them up or multiply them, but that breaks the equal distribution of numbers and some values will happen more often than others. It's easiest illustrated with a few small values. Let's take a range from 0 to 2 inclusive. All possible combinations:

0+0, 0+1, 0+2
1+0, 1+1, 1+2
2+0, 2+1, 2+2

If you take a close look at all possible combinations, you will notice that the results are not equally probable. 0 and 4 appear only once, 1 and 3 appear both twice and 2 appears 3 times as a result.

The only way to really handle this issue is to combine the values in a way that preserves the equal distribution. If we simplify the entire thing and say it's only possible to generate 1 bit randomly, we can get the values 0 or 1. Now if we do this procedure N times, we can get a number that consists of N bits and all numbers generated in such a way will always be equally likely to appear and the distribution will be preserved. Since we already have 15 bits (32,767) at our disposal to be generated, we can just generate this value twice and then just combine them by shifting one of the numbers to have a 30 bit value.

I implemented this in our foundation library, you can take a look here at line 46 and 47 (or just find "#define HRAND()" if the code has changed since this post was made): https://github.com/AprilAndFriends/hltypes/blob/master/src/hltypesUtil.cpp
I do casting to int64_t, because I have multiplication and division with another 32-bit int so nothing breaks. Incidentally I think this is the same reason why Microsoft limited RAND_MAX to 32,767 in the first place.

20
Sea of Code / Another reason why WinRT is shit
« on: May 11, 2017, 11:13:20 AM »
So today I had to work with WinRT again. It was with sockets and WinRT has their own socket implementation. So no c-style sockets are allowed.

The main first issue is the problem that WinRT can't handle reading an "endless" stream from a socket. The problem point is the IInputStream::ReadAsync() method (because everything in WinRT MUST be async). Once you run the method, you can a special AsyncOperation object. You can assign a "Completed" delegate to that object and once WinRT reads at least one byte from the socket, that delegate will be called. Now, the issue here is that if there are no bytes available for reading, WinRT will wait an undefined period of time. This can be a timeout of apparently 180 seconds (somebody mentioned that information somewhere on Stack Overflow, I don't know if it's correct) or basically indefinitely. The catch is that there is no way to ask WinRT whether there are any bytes available for reading. So if you want to keep reading for a while or are wrapping sockets into a higher level system, you are fucked.

Now hold on. Yes, this is nasty, but this is only the introduction into the probably biggest async API design flaw I've seen in my entire life. Prepare yourself for a next-level fuck-up of multi-threaded programming.

So I kept thinking about this issue and an effective way to circumvent it. And I came up with something. I decided to use a buffer which I would then check for data in my main thread method call where I want to receive the data while I just keep calling ReadAsync() and let it do its thing.
Since we're working with async calls here and shared data between what appears to be separate threads (waaaaaait for it...), obviously this data needs to be protected with a mutex (this is a locking mechanism that prevents threads accessing the same data at the same time since threads are undeterministic). So I did that. But suddenly I would keep getting deadlocks sometimes (this is when an already locked mutex is locked in the same thread again and basically means freezing of the thread). I was surprised how this was possible. And then it hit me. I did some testing to confirm my theory and I was right.

You see, usually that "Completed" delegate callback should be called from a different thread. So using a mutex to protect data is absolutely necessary. There is no other way. And most of the time that's exactly what WinRT does. Except when it doesn't. It's possible that ReadAsync() actually finishes before you assign the "Completed" delegate. And you know happens when you finally do assign it? The callback gets called immediately IN THE SAME THREAD WHERE "Completed" WAS ASSIGNED! So if you locked a mutex before assigning "Completed" and then you have to lock that mutex withing the delegate that was assigned to "Completed", you will get a fucking deadlock! Fuck you, Microsoft! Fuck you!

The good news is that I was able to resolve the deadlock by unlocking the mutex before assigning "Completed". But fuck Microsoft and their asynchronous-but-sometimes-it-isn't API. >:(

Here's the final code so you have an easier understanding what I've been struggling with. I added a few comments to make it easier to understand

Code: [Select]
// this workaround is required due to the fact that IAsyncOperationWithProgress::Completed could be fire upon assignment and then a mutex deadlock would occur
hmutex::ScopeLock _lockAsync(&this->_mutexReceiveAsyncOperation); // ScopeLock makes sure the mutex is unlocked when this method finishes (very useful when throwing exceptions, etc.)
bool asyncOperationRunning = (this->_receiveAsyncOperation != nullptr);
_lockAsync.release(); // has to unlock that mutex again...
if (!asyncOperationRunning)
{
try
{
this->_receiveBuffer = ref new Buffer(this->bufferSize);
this->_receiveAsyncOperation = inputStream->ReadAsync(this->_receiveBuffer, this->bufferSize, InputStreamOptions::Partial);
this->_receiveAsyncOperation->Completed = ref new AsyncOperationWithProgressCompletedHandler<IBuffer^, unsigned int>(
[this](IAsyncOperationWithProgress<IBuffer^, unsigned int>^ operation, AsyncStatus status)
{
if (status == AsyncStatus::Completed)
{
IBuffer^ _buffer = operation->GetResults();
Platform::Array<unsigned char>^ _data = ref new Platform::Array<unsigned char>(_buffer->Length);
DataReader^ reader = DataReader::FromBuffer(_buffer);
try
{
reader->ReadBytes(_data);
hmutex::ScopeLock _lock(&this->_mutexReceiveStream);
this->_receiveStream.writeRaw(_data->Data, _data->Length);
hlog::errorf("OK", "async data: %d", _data->Length);
}
catch (Platform::OutOfBoundsException^ e)
{
}
reader->DetachBuffer();
hmutex::ScopeLock _lock(&this->_mutexReceiveAsyncOperation); // ... because this lock here might as well happen in the same thread as the one at the beginning of this code and cause a deadlock
this->_receiveAsyncOperation = nullptr;
this->_receiveBuffer = nullptr;
}
});
}
catch (Platform::Exception^ e)
{
PlatformSocket::_printLastError(_HL_PSTR_TO_HSTR(e->Message));
return false;
}
}
... // down here I lock this->_mutexReceiveStream and read from this->_receiveStream, but it's not relevant to this issue

Pages: [1] 2 3 ... 40