Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Apr 2000
Offline Last Active Today, 07:40 AM

Posts I've Made

In Topic: Weird behaviour when changing RIDEV_CAPTUREMOUSE on register

15 August 2014 - 10:41 AM

I forgot to mention that if I change my Exclusive mode via a keyboard key press (KeyDown -> Exclusive = TRUE, KeyUp -> Exclusive = FALSE) then it works flawlessly.  So that makes this even more weird.

In Topic: "unofficial" programmer rant thread

05 August 2014 - 01:16 PM

Oh boy!  Complaining!  I'm good at that!


OK, I do a lot of crap in my job, everything from desktop apps to web apps to ritual sacrifice of junior developers.  


I ABHOR web development.  It's a bloody mess.  Everything from ASP.Net (which for simplistic things, is not too terrible) to the back and forth between client - server via Javascript.  I avoided learning that bastard of a language for years, and every day I'm reminded of why.  


Then there's the plethora of stuff that sits on top of Javascript to make life "easier" (jQuery, node, etc...).  Except it doesn't, especially when you have to work with people who think that version numbers are meant to be ignored and different code bases can be mixed with ease (of course, that could be defined as a PEBKAC problem).  Don't even get me started on the browser issues (and no, Microsoft isn't the only one to blame for this).


That said, this thread actually reminded me of something I thought about last week.  I had stumbled upon this blog of this dude who was writing stuff for unchained VGA mode (Mode-X for the old people) in DOS.  Then he decided to port it to CGA, EGA, Tandy/PCJr, C64, Amiga and his toaster.  So, that inspired me to do something that I always wanted to do since I was 12:  Write graphics routines for EGA.  There's a ton of reasons why I never learned this when I was younger.  Most notably, the internet not being the wonderful warehouse for porn and cat pictures knowledge that it is now.  And that I couldn't actually get access to it until I was much older.  But I digress...  old people like me do that sort of thing.


So, with that long winded explanation in mind, I opened up Dosbox and installed a copy of Borland C++ 3.1 and began my code.  And now, to the point:  I realized just how easy it was to set up Borland C++ and just start writing.  And I realized just how easy it was to open 320x200 16 colour mode and plot a pixel and then many pixels.  I contrasted this to writing Direct3D (or Open GL for those that like that sort of thing) and realized that it is a major pain in my ass to get even the most simple things up and running (and I usually work with C#, so it should be stupid simple).  I often get burned out because of all the boilerplate before actually doing something interesting.  And I didn't even remotely experience that with my DosBox/BC++ experience, I actually felt like I was accomplishing something.  


Anyway, yeah, that's my rant.  Things are too damned complicated.  And kids are on my lawn!  And the rent is too high!  And... I'm tired... I have to go nap now.

In Topic: Weird corruption when drawing text with DrawString

08 March 2014 - 06:59 PM

OK, so I finally found another person that has run into the same problem (this is from 2012... I'm astounded it's still an issue):



In the end I used the GraphicsPath method described by Gianpaolo64 (in the aforementioned link) and that solved my issue.


In Topic: Per Pixel Lighting

16 October 2013 - 11:22 AM

This is your problem:

    Output.Color = baseColor *(lightFactor+xAmbient);
    Output.Color = tex2D(TextureSampler, PSIn.TextureCoords);

It should be:

    Output.Color = baseColor *(lightFactor+xAmbient) * tex2D(TextureSampler, PSIn.TextureCoords);

Or something similar to that.

In Topic: Display Images fast with SlimDX .

19 August 2013 - 11:18 PM

Looking at your code, I'd move the TCP read and filling of the memory stream to another thread.  That way it can handle that part in the background and free up some CPU time.


Again, as for the decoding from the memory stream using FromStream, I'd just create a dynamic texture (outside of the loop) and just continuously update it.  This is where putting your stuff into another thread could help. You could decode the image data in the other thread and copy the data into a format that's friendly to the texture, and then when it's done filling the memory stream (and you're back on your main thread) you lock the dynamic texture, and just dump the contents directly into the texture and unlock.


You can still preserve the behaviour you have now.  That is, no image, then you show nothing (empty texture), first image arrives, it gets displayed, subsequent image arrives, and it gets displayed, nothing else arrives so just use the last image.  You need only update the texture after the memory stream has been filled with data.


Again, that's how I'd consider handling it, and it may not be the best way, but I do know that creating the resource and destroying it every frame is just bad for performance and I don't think there's anything you can do to improve the performance with the code as it is.