Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2005
Offline Last Active Yesterday, 10:29 AM

Topics I've Started

VS2013 IDE/intellisense + VAX + performance (a kind of a rant-question-thing-thing)

22 August 2014 - 12:24 AM

I only just got my brand new VS2013 set up and I opened up my main project for some tinkering with the IDE. My first impression was that while the editor is certainly easier to customize, looks better and provides more features, it is also unbelievably sluggish compared to 2010. Beginning a block comment sometimes takes 2+ seconds to alter the commented out text. Opening glew.h (15k lines) takes several seconds before I can interact with it and even then scrolling is incredibly slow and uneven. What really dumbfounded me, however, was intellisense's behavior.


I'm not sure whether it is the built-in intellisense or VAX that is causing this, but it stops happening when I disabled either one of them. Namely, I had an ad-hoc member variable __bDirty which, when auto-completed via the intellisense's pop-up list, wouldn't be inserted into the code editor. I had no idea why that was the case until I hand-typed it in and ran build. As it turned out, the name __bDirty had indeed been inserted, but at the very top of the file. So I thought "fine, names starting with underscores are reserved and screw up intellisense or something". I refactored it to something more standard, eg bDirty, but lo and behold - it still behaves the same way. I love VAX and as mentioned above, the name is inserted properly when I disable the built-in intellisense (as in, completely). So I did that.


But guess what - when you disable the built-in intellisense, you also lose any automatic functionality in the peek window! It starts behaving like the default Find prompt:if you peek a variable named stack, it simply lists all known declarations of variables named stack, regardless of what type they are or what class they belong to - and if the header file isn't added to the project, that particular declaration won't even appear in the list.


Now, my IDE is presumably fully up to date (12.0.30723.00 Update 3) and by now the dev team has had plenty of time to patch it left and right. But considering the frankly astonishing sluggishness of the editor, which I specifically read had been addressed and would be far less palpable than in 2012, which I skipped over, I feel like a complete idiot.


Now, to be fair, the misplaced auto-complete string seems like a conflict between both VS and VAX and it's hard to place blame here. I've been a long time VAX user on 2010 and since I would need to purchase a new license anyway, I intentionally got the latest trial version (10.8.2043.0) to try it out so I could see how polished the experience was. But this auto-complete thing ain't a small bug. It's one of those giant brain-sucking bugs from Starship Troopers, and the fact after all this time something like that still crops up, is quite honestly ridiculous.


Anyway - just to be sure: have I missed some update or patch or something or is the sluggish behavior really normal? I've tinkered with enabling and disabling GPU acceleration in the IDE properties, but I'm still having major problems scrolling in files that are any larger than a few thousand lines.

Anyone played Jazzpunk yet?

13 August 2014 - 12:48 PM

It's on sale on Steam right now. Took me about an hour to degauss three pidgeons, Xerox a park, contact Kremlins 2: The New Batch, watch censored cell porn and catch packets for a frog through its data visor. 


Even before I've played through it, Jazzpunk rates up there among the few truly fresh and invigorating reasons I keep trying out new games, along the likes of Thirty Flights Of Loving, Tower Of Guns, The Stanley Parable, Dear Esther, The Unfinished Swan and Broforce. Edit: oh, I forgot to mention my recent puzzle crush The Swapper!


Swing wing!

Viscosity and volume mixing in fluid dynamics

27 July 2014 - 12:13 PM

I've been working on a rather simple fluid dynamics implementation that I now wish to expand. I have my single-fluid vortices up and tracer particles following the velocity grid. However, I'm trying to figure out a way to create a mix of fluids that interact upon friction.


Since I'm not up to speed with the terminology, I'll just describe what I want in my own words: what I have in mind is a "non-particulate" (eg closed, fixed volume) flow map that always fills the entire region. Though it would be my next step, compressible fluids isn't something I outright need. So far as my knowledge goes, while the latter would be a solution, I'm not sure whether the answer in this case is somehow propagating the material type based on the density map or populating the entire chart with particles and making them all one unit in size.


Another thing I'm not entirely sure how to implement is shearing and fluid mixing based on viscosity differentials. Here's my test setup:



Attached File  fluid dyanmics.jpg   67.55KB   0 downloads


The screenshot is of a horizontally wrapping velocity grid where blue tones = left-moving and red tones = right-moving. Green = stationary. Color brightness denotes velocity, also shown by arrow lengths. The bright lines between the bands are the regions where flow directions cancel each other out, so shearing occurs as expected, but no mixing.


The reddish dots are tracer particles used to gauge flow.


Ideally I'd like to see adjacent bands start mixing at the boundary layer due to viscosity while none of the layers loses volume (eg the amount of material that each band comprises remains the same throughout the system). I suppose the closest example to this would be any horizontally closed system, such as a gas giant.


I'm looking for resources with less emphasis on the math and more on implementation (seeing as I'm not as mathematically well-endowed as I would like to be) - Googling has had me jump around from one place to another and it turns out finding good information isn't quite as straightforward as I would've hoped.

Inter-thread communication

16 July 2014 - 04:46 PM

tl;dr - in short, this is a question of how to best implement my own version of PostThreadMessage().


More precisely, my target problem right now is communication between the input and render threads in the context of a GUI. I'd like this very same logic to be extensible to communication between the input and game logic threads, and load and render threads. I've kind of settled on a fairly simple counter-based method as I've come along, as it just works.


My assumptions are:


- I don't want to use a locking mechanism

- instead I either use polling in the render thread if running in real-time mode, or signaling via something like a waitable object to force a refresh, if not running in real-time mode. This bit I'm somewhat worried about as I'm not yet sure as to how portable it is.

- I'd like the communication scheme to be extensible to any many-to-one thread model where many threads can send messages to one target thread


With this in mind the best (and so far only, really) way I've managed think of is a FIFO stack with each sender thread having its own dispatch queue and a write marker that points into a circular buffer (eg the stack). The receiving thread then reads everything from its respective read marker up to the write marker at each iteration (or when notified). There is no synchronization between the two threads other than a possible SetEvent() called by the sender if the render thread doesn't already poll in a tight loop.


So far this has been a fairly straightforward and foolproof approach. The primary problem I see here is guesstimating the size of the message buffer and, in particular, what to do when an overflow occurs. Before going about reallocating memory to fit more messages I figured it'd make sense to actually see if there might be more trickery involved in the way Windows does it (yeah, that was a question).


Also, in a way it feels a bit like a hack, even though it works :)

Exception handling, debugging a custom memory allocator and working with first-chance e...

30 June 2014 - 10:39 AM

The problem: I've been working on and fleshing out my codebase for several years now and a vast majority of the time it works as expected. Nevertheless, there are occasional oddball situations that can easily lead to bug hunts that last for several days and often result in my finding various (seemingly) unrelated bugs that often also solve the problem at hand, but in a very obscure way. In such situations I often have nothing more to do than shrug and carry as if something so inexplicable happened that it defied the laws of physics. Some of this has to do with code complexity; however, I suspect more than that, this has to do with my knowledge of how to handle these situations.


The setup: I'm writing a multi-threaded application that currently branches into two primary threads - the render thread and the input thread. Both have SEH exception handlers at the stem: surrounding the entire body of code in the render thread and in the WNDPROC callback in the input thread. I'm catching all standard exceptions.


Where it gets complicated: every now and then I stumble upon a first-chance exception that throws off my entire program. Now, I know what a first-chance exception is and I know why it's being thrown the way it is. However, the root cause for it is usually an access violation, which is always terminal in nature. Using the Disassembly window I can look up what's at the address where the exception is thrown, but generally the it seems to be thrown in unmapped address space, which a) doesn't really help with pinpointing the cause and b) gives no indication as to where where or when it was thrown.


Where it gets more complicated: I'm using a custom memory allocator that I wrote. Is it bug-free? Good question. The bottom line is, it's not too complicated and doesn't support fancier features like reference counting or compaction. But it's fast, multithreaded and it gets the job done. At least as far as I can tell. It also makes debugging considerably more obscure.


The confusion: here's a very short snippet of code that exemplifies a common case of confusion. The following is a response to keyboard input and crashes always in the same way at the same moment. I've gone over the code preceding it and I can't find anything that might write into an invalid memory address (directly or remotely via another thread). I do recognize that this kind of inspection is concessional and doesn't really guarantee that I didn't miss a bug. Nevertheless, this is still a fairly strong indicator that by all logic the access violation cannot occur in any other thread (since it's temporally locked to user input) and has a low probability of occurring sometime before the below snippet is executed. This, in turn, completely screws up any and all logic when it comes to tracking down the cause:

int Editor::HandleKeyboardInput(...)
   if(toolActive) { toolActive->Activate(false); }
      toolActive = newTool;
   if(toolActive) //all cool in the Watch window
      toolActive->Activate(true); //BOOM! crash, because all of a sudden the 'this' pointer is NULL!
                                  //EDIT: apparently the 'this' pointer is modified only occasionally; other times newTool's
                                  //Activate() starts pointing to unmapped space

Running the debugger through this with application-side exception handling disabled just gives me an infinite loop of first-chance and second-chance exceptions that point to exotic memory addresses.


The solution? I've gone back to manually commenting out code blocks and ultimately it's not impossible to arrange code in a way that gets rid of the exception. However, the logic, which surrounds tracking something like this down still eludes me and I find myself resorting to trial and error, which frankly has a really poor probability of identifying and fixing the actual error that's causing this. After all, I've gone over everything ten times now and most permutations that do get ride of the crash (at least in terms of how I rearrange my code) don't make much sense.


So, to recap - if anyone can point out glaring holes in the way I'm handling exceptions in my code, comment or criticize on the way I'm tracking them down or provide overall suggestions, I'd appreciate it a lot. I realize the problem is likely something as silly as writing past a an array boundary (even though I'm using guarded arrays in debug mode...), but experience has proven that the more innocuous the bug, the more days or weeks it takes to track down.


Oh - in case it becomes relevant, I'm on VS2010, Windows 8.1.