Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Jun 2011
Offline Last Active Aug 22 2016 08:41 AM

#5122074 Find Direct3D device

Posted by on 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"

#5118404 Double Screen Resolution

Posted by on 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.

#5075181 Problem with shooting bullets in both directions (Platformer)

Posted by on 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.

#5055935 Accelerated C++ chapter 3 help needed.

Posted by on 22 April 2013 - 11:53 PM

That's because whatever invalid input cin tried to convert into x's type is still in the buffer.  What's wrong with simply ignoring the remainder of the invalid input with cin.ignore()?

#5055879 Accelerated C++ chapter 3 help needed.

Posted by on 22 April 2013 - 06:00 PM

It's a bit subtle.  http://www.parashift.com/c++-faq/istream-and-while.html


In a nutshell: your while loop continues until the user puts the stream into an error state, after which all attempts to extract data from it will fail until the error state is cleared.  After the loop, reset the stream's state with istream's clear() function (cin.clear() -- as cin is just an istream under the hood)


As an aside, you can still break things in the same way by providing invalid input for the first two cins.  For instance, typing anything that can't be cast to a double for the midterm or final grades will also put the stream into an error state and skip past the loop and your final cin.  It might be wise to check the stream's state after those to see if the user tried to input something invalid.

#5045432 SDL multiple layer - why doesn't this work?

Posted by on 21 March 2013 - 06:28 PM

Is your image loaded successfully?  Right after img would be a good place to display SDL_GetError() if img turns out to be NULL.


Also: Don't assume you know the underlying pixel format.  For instance, on my computer your masks are wrong.  Just use the screen's format.

SDL_Surface* img = IMG_Load("blocks.png");

    if (!img) {

        std::cout << "Error: " << SDL_GetError() << std::endl;

        return -2;


SDL_Surface* f1 = SDL_CreateRGBSurface(SDL_SWSURFACE,500,500,32,_screen->format->Rmask,




After that, blitting with the alpha transparency worked fine for me.

#5037717 Odd usage of friend keyword in C++ class.

Posted by on 28 February 2013 - 02:04 PM

In the interest of a direct answer: that's a forward declaration wrapped in a friend clause.


class Foo {
    friend Event;

class Event {};

Compiler error - error C2433: 'Event' : 'friend' not permitted on data declarations



class Foo {
    friend class Event;

class Event {};

No problem!  Equivalent to:


class Event;

class Foo {
    friend Event;

class Event {};


Apologies if this was obvious.  If your question has to do with why it's being used like that, I haven't the faintest idea.  It appears event, request and response are tightly coupled for some reason

#5032560 Allegro Shooting Projectile help

Posted by on 15 February 2013 - 04:24 AM

Assuming your UpdateBullet function is the "updated" one from your second post, you've got a logic error in there.  Think about this: why are you iterating over all the bullets again after you've determined the direction bullet[i] is facing?  Shouldn't you be updating that one, single bullet based on its own direction?

#5032510 Allegro Shooting Projectile help

Posted by on 15 February 2013 - 01:31 AM

Thanks very much for your help, i've nearly got it working. I've changed the bulletdir into the switch. 

Under init bullet if I manually enter the direction it fires perfectly but i'm now having a hard time getting the tanks direction in there. I've tried doing it 2 ways, as listed below.



Trying it either way only shoots right.


You want to set the direction of the bullet at the time of firing, i.e. in FireBullet.  It always goes to the right because you set the bullet direction in InitBullets to 1 (right) and then never change it.  Add

bullet[i].bulletdir = tank.dir

To your for loops in FireBullet.


Also, consider improving readability a little.  For instance,

enum Direction {
NORTH = 0,
EAST = 1,
SOUTH = 2,
WEST = 3


And perhaps a function to locate a dead bullet index for you:

int FindDeadBulletIndex(Bullet bullet[], int size) {
    for (int i = 0; i < size; ++i)
        if (!bullet[i].live)
            return i;

    // didn't find an index; maybe delete old bullet or similar?
    return -1;


Then your new FireBullet might look like this:

void FireBullet(Bullet bullet[], int size, TankPlayer &tank) {        
    int index = FindDeadBulletIndex(bullet, size);

    if (index < 0)
        return; // no "open" bullet positions available

    bullet[index].live = true;
    bullet[index].bulletdir = tank.dir;
    // set bullet position to tank's position ...
    bullet[index].bulletX = tank.x;
    bullet[index].bulletY = tank.y;

    // ... or adjust position based on direction, if you want:
    if (tank.dir == NORTH) {
        bullet[index].bulletX = tank.x;
        bullet[index].bulletY = tank.y + 17;
    } else ... // and so on

#5032242 Allegro Shooting Projectile help

Posted by on 14 February 2013 - 07:25 AM

You've almost got it.  In UpdateBullet, you calculate its direction based on which way the tank is facing.  Change the switch to query the bullet's bulletdir instead.  Then copy the tankdir into the bullet's bulletdir every time you set up a new bullet.

#5025797 Pointers invalid between C++ and C#.

Posted by on 26 January 2013 - 11:24 AM

It sounds like your program and the DLL its calling have different memory heaps.  A pointer returned by allocating memory in your editor heap will be invalid when you try to use it to locate data in your C++ DLL, but it will look perfectly valid when debugging from the editor. 


I don't know anything about C# so I can't point you anywhere specific, but usually sharing allocated objects across processes is done with shared memory segments or memory mapped files.

#5016170 Huge territories.

Posted by on 31 December 2012 - 02:45 PM

You might find http://scottbilas.com/files/2003/gdc_san_jose/continuous_world_paper.pdf interesting.  They talk about the precision issue under "terrain implementation."  It might give you some ideas

#5009971 How to create and work with not tile based map?

Posted by on 12 December 2012 - 03:31 PM

Uh, I am note sure what you mean with "Sort the polygons spatially in some way"? You mean drawing polygons one by one? This might be what they do cause there is a file that represents rectangles that define extreme borders of the province in question (left, top, bottom, right). In this way they know where to draw the province although I have not seen single province images. They might acquire them from the big map or somehow?

It's a matter of performance. You don't want to try to draw every province, army, arrow, etc every frame. Instead, you want to draw what the user can see. You're already on the right track: calculate axis-aligned bounding boxes and then sort them with some simple algorithm. Then, you can query your sorted bounding boxes to see which polygons lie in an area. You'll end up using this for a lot of things: for instance, in addition to rendering you could also use it to narrow down possibilities for which province was clicked, or have the AI use it to determine how many hostile armies are within range of a given province, and so on.

A really simple way to do this might be a balanced binary search tree sorted by the x or y axis. There are lots of tree variants though. Search "spatial partitioning" for more ideas.

I cant imagine an editor with indenpendetly drawn provinces? How do you control their precise position on map?

You use your editor* (that you'll write to work with the game) to place provinces wherever you want. You would have two files: 1 is the map, which could be just a simple BMP. The second would define vertices that make up the provinces and possibly contain any particular details (for instance, starting points or region wealth or city locations, whatever features your game has) that can be changed via the editor.

* I've never used gleed2d so I don't know if it'll do what you want or not, but if it does that could save you a considerable amount of time.

All adjacent provinces are kept in a file similar to the one I described for hit testing. There is a province Id, followed by ids of adjacent provinces so its easy to know where you can go.

That works. You could have the editor define that for you, or have the game engine figure it out while loading the map to make things a little more automatic. Either way.

I am not sure if Python has such library, I am even not sure can it be done in Python? But I need some more info about substance of working with maps like this one.

You could probably come up with your own solution pretty easily. I was getting ahead of myself and thinking about the editor automatically filing in oceans and unused areas, or randomly generating a set of provinces on any given map. A way to define polygons and a function to check if a point is inside any given polygon is really all you need or want at this point.

#5009837 How to create and work with not tile based map?

Posted by on 12 December 2012 - 08:38 AM

Why not define provinces in terms of polygons? Sort the polygons spatially in some way and then a point-in-polygon test to determine exact polygon that's been selected. This has some advantages:
  • Your artist could create any kind of map with any kinds of colors and details on it. An editor could be used to draw out the borders of the provinces. No requirements would be placed on the map, so your artist could add trees and other fine details without issue. This also means you could release the editor to your players and have them create their own maps easily if they wanted.
  • You could easily determine which provinces are attackable from a given province based on which edges are shared. This would additionally make it easy to draw those attacker arrows, since you would have well-defined edges and could select the most visually appropriate one pretty easily
  • Territories can be any shape (as long as the polygon isn't complex) and border any number of provinces (or none--say, an island)
  • Those overlays based on territory, economy or what have you would be really easy to implement. Just overlay a translucent filled polygon on each territory. You could also use the province's polygon to clip drawing on that province -- say, if you wanted to draw a texture on it.
Boost has a really nifty Polygon library for C++ that would make this a snap. I'm sure Python has something similar you could use.