Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 05 Jun 2011
Offline Last Active Nov 28 2014 11:48 PM

Posts I've Made

In Topic: Find Direct3D device

07 January 2014 - 11:12 PM

Sure it can be done.  I assume you don't have control of the process that owns that handle, so what you'll be needing is 1) a strategy to get your own code running inside that process and 2) a strategy to find the device pointer once you're inside.


The simplest solution is a proxy DLL, which would cover both cases nicely.  Some helpful articles could be found by googling "DirectX hook proxy dll"

In Topic: Double Screen Resolution

20 December 2013 - 12:44 PM

You're going about this the wrong way. You can
  • reduce the screen resolution and use your graphics at their current size, or
  • scale your graphics up as part of the resource loading process rather than trying to scale the entire screen (or individual surfaces) on every frame, or
  • scale your graphics up in whatever you're using to create them so that they're the correct size relative to your desired resolution
Doing any kind of pixel manipulation is going to be very slow in SDL1.2 so offload as much of it as you can into one-time processes performed at startup.

In Topic: Problem with shooting bullets in both directions (Platformer)

03 July 2013 - 09:17 PM


for(int i = 1; i <= counter; ++i)
if(player.getHDir() == 1) // '1' means the player is facing to the right
bulletX[i] += bulletSpeed;
bulletX[i] -= bulletSpeed;
circlefill(buffer, bulletX[i], bulletY[i], 5, makecol(15, 50, 255));

You base the bullet's direction on the player's facing.  Turn bullet into a struct or class with the properties X, Y, and direction (or create yet another array for the bullet direction, though this is clunky).  When you shoot a bullet, copy the player's direction to the bullet's.  Then when you update bullet positions, use the bullet's own direction.


A cleaner way of doing this would to instead give each bullet a position and velocity vector (speed + direction) when fired.  Then there's no need for an if statement at all and bullets could travel in any direction.  Simply add the velocity vector (* elapsed time) to the bullet's position vector during each loop.

In Topic: Digging Tunnels In Map

28 June 2013 - 01:28 AM

Funnily enough I ran into this exact problem (and I mean exact) some time back.  Tunnels were represented by a connected graph.  The map itself was a plane made up by a fairly dense grid of vertices.  When a tunnel was added, I swept along the path from origin node to the new node, deforming the plane's vertices in a half-cylinder with a touch of randomness to avoid perfectly smooth walls and with a taper as it reached the end.  This was done gradually as ants arrived at the "dig" site to "grab" a small piece of dirt to haul it to the surface.


In my case I didn't need a collision mesh as ants would always take paths connected by nodes and never ventured outside of those paths.  You could create one as you constructed tunnels fairly easily though.


If you're looking for a two-dimensional solution, one easy way (and the way I started out initially with HGE before switching to Ogre3D) is to create two layers.  One layer represents "dug" tunnels, the other a "cover" layer showing dirt.  As you create tunnels, erase parts of the cover so that the bottom layer shows though.  I've actually got a screenshot of that version:


In Topic: Good indie games?

25 June 2013 - 09:18 AM

Have you tried Super Meat Boy or Fez?