This is bad to say, but as I was debugging and cleaning up code, the problem went away.  :?:  So I don't know why it was happening but again.. it is gone.   :roll:

Código [Seleccionar] Expand

// cascades the sprites
CRM32Pro_CSprite* cspr = get_spr(spr2);
cspr->SetPosition(10, 10, 0);
cspr = get_spr(spr3);
//cspr->SetPosition(20, 20, 0);
cspr->AutoRestore(0);

//cspr = NULL;

int x = 60, y = 60;

while(!done)
{      
++x; ++y;
cspr->SetPosition(x, y, 1);
spr_man_logic();

while(CRM32Pro.Update(&event))
{
switch(event.type)
{
case SDL_MOUSEBUTTONDOWN:                
break;
case SDL_QUIT:
done = 1;
break;
case SDL_KEYDOWN:
if(event.key.keysym.sym == SDLK_ESCAPE) done = 1;                    
break;
default:
break;
}
}
}

I've tried multiple methods, but the result is always the same - The sprite seems to repeat the path, drawing copies of itself throughout the path.

I've done exactly what the rabbit example does with movement. yet, it's crud. What did I miss?

spr_man_logic() simply sorts the sprites on a per layer basis, and checks for collision, it does nothing with the sprites position.

I will run some tests and send you what I find. I'm currently doing alot of design crap that I wish I could skip for this game but I can't. Code is on hold for awhile.

I was wondering how the collision is done with the Collision method. Once collision is found out the be probable - Does it check every pixel of both sprites?

 If so, here is an article on how you can cut out alot of useless pixel checking..

 http://www.gamedev.net/reference/articles/article754.asp

 Is this method similar to the one used in CRM32Pro? Or does this one cut down on pixel-checks?

 I've been looking for ways to *avoid* extreme performance loss on collision checks, because I simply cannot use the Collision method provided by CRM32Pro.

Has any one else had such high performance loss with this method?

 Anywho.. Going back to gamedev to read more. ;)

Very nice! I like it. EditorDPF feels more like a proffessional game data compression utility than before.

Setting the colorkey and hotspots in the editor eases programming so much.  

Sweetness.   8)

Cool!! I will get the latest update!

 One more thing, what about getting a sprites width and height? Is their a member or members to do this? I looked throughout the documentation for something like it, but all I found in the headers was.. CRM32Pro_CSprite::GetOffset(int *, int *) .. Is that the member I want to use ??

 Anywho.. The game engine is about 70% done, most of what's left is scoring code, weapon selection code, bonuses code and menus code. I haven't used the audio very much, but it is implemented. (probably the easiest thing to add to the whole project!) After all that is done the more annoying project starts, the level editor.

Hm.. I swear I replied to this a couple of days ago, but it's not here.. So anyway..

About the unusual sprite size, the .DPF tool limits you to 16x16 sprites as the smallest sprites you can use - this is why I end up using sprites sizes too big for some sprites..

The collision granulty sounds like a great idea! But also, with that bit you said about the red-rectangle showing the collision area, maybe you could add a BB_Collision() member or something that only uses a _tightly_ bounded box?? (which is calculated simply by finding the outer-most pixels.. which can be done when the sprite is loaded.. but you know this.  8) )  Less accurate, but it's a nice option if you want to pass up the current implementation for collision in favor of performance.

Having lots of collision options is my cup of tea. Sometimes you need pixel by pixel, and sometimes you need every other pixel, and sometimes you just need to check a bounding box.

But the "granularity" idea sounds cool! You could cut collision check time by at _least_ half.

One more thing, I've looked over the docs, but I haven't found this feature, I want to get the size of a sprite. Is there a member?? Something I missed somewhere?

Anyway, thanks and happy holidays!

One more thing, which I doubt can be improved any more - CRM32Pro_CSprite::Collision() lags the entire game when it is called.  :!:

  I do check to make sure the two sprites being collision checked are close enough that collision will probably be true before attempting to call Collision().

 Of course, when you have an 8x8 bullet in a 16x16 sprite, or a 24x20 ship in a 32x32 sprite, without calling Collision() there's gonna  be alot of "HEY THAT DIDN'T HIT ME!!!" or "HEY I DIDN'T MISS HIM!!!" going on. (like in quake 1, 2 and 3 because models would go outside their bounding boxes when running)

 Anyway. I know there probably isn't much hope for a fix there. :) It's cool.. I can make it an option in a menu for newer PC's (1.5ghz +).

Well, truthfully I'm not sure exactly how you expect it to run, but if I change it from say OPEN_GL to the default (for win xp) the performance drops by at least half, but the logic does not seem to make up for the performance drop.

 But I don't know _alot_ about timing mechanisms. I only know enough to make my own and hack it together until it does what it should.

As long as I can get victims to test my game, I will continue to work on the performance and timing. But maybe the timing is doing what it's supposed to now?

I really enjoy using CRM32Pro, you've already done all of the exhaustive work for me! WOOT!! Praise CRM32Pro!  :wink:

I do know what you mean, but it's not working like that. I placed the code like you said.. *shrug* I'm packaging everything now for you.

Whats a game without particle systems?!?! Haha.

   Hm. So OpenGL is stable enough then? Lets see.. Wowee! Well it's _too_ fast haha! Getting ~400 fps. The ship did have a max speed of 8.0f, I kicked that down to.. 3.0f. May have to drop it even further down, to about 1.5f - 2.0f.

   Let me build another stable copy to send to you so you can tell me how the speeds feel on your PC.

   BTW the code has had some major changes.   :twisted:

I split the Do() members into Logic() and Render() and threw Logic() into the CRM32Pro.Update(&event) loop, while Render() stayed in RenderGFX() and it's running better now, not perfect, but better. :) I'm sure in fullscreen it will run how it should. But we'll see when there's 20 flyers on the screen with all kinds of bullets and particle systems running. hehe

The table wouldn't copy-n-paste correctly, so here's the text readout:

øû (x86 Family 6 Model 8 Stepping 6)
· CPU Speed: 863 Mhz
· System memory total/available: 319Mb / 82Mb
· ATI Technologies Inc. - RADEON 9600 x86/SSE - 2.0.6012 WinXP Release
· Screen resolution 800x600x32bits

· Test 1 using 'software' engine.
-> Number of sprites: 100
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Screen has double-buffering enabled
-> Sprite is in video memory
-> Sprite blit uses hardware acceleration
-> 84.49 frames per second

· Test 2 using 'software' engine.
-> Number of sprites: 1000
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Screen has double-buffering enabled
-> Sprite is in video memory
-> Sprite blit uses hardware acceleration
-> 33.31 frames per second

· Test 3 using 'software' engine.
-> Number of sprites: 100
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Sprite is in video memory
-> Sprite blit uses hardware acceleration
-> 353.27 frames per second

· Test 4 using 'software' engine.
-> Number of sprites: 1000
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Sprite is in video memory
-> Sprite blit uses hardware acceleration
-> 35.84 frames per second

· Test 5 using 'software' engine.
-> Number of sprites: 100
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Screen has double-buffering enabled
-> Sprite is in video memory
-> 612.73 frames per second

· Test 6 using 'software' engine.
-> Number of sprites: 1000
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Screen has double-buffering enabled
-> Sprite is in video memory
-> 233.31 frames per second

· Test 7 using 'software' engine.
-> Number of sprites: 100
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Sprite is in video memory
-> 886.92 frames per second

· Test 8 using 'software' engine.
-> Number of sprites: 1000
-> Screen is at 32 bits per pixel
-> Screen is in video memory
-> Sprite is in video memory
-> 209.42 frames per second

· Test 9 using 'software' engine.
-> Number of sprites: 100
-> Screen is at 32 bits per pixel
-> Screen is in system memory
-> Sprite is in system memory
-> Sprite blit uses RLE acceleration
-> 31.15 frames per second

· Test 10 using 'software' engine.
-> Number of sprites: 1000
-> Screen is at 32 bits per pixel
-> Screen is in system memory
-> Sprite is in system memory
-> Sprite blit uses RLE acceleration
-> 4.47 frames per second

I will try all this tomorrow.. Well.. Later today actually. I need to get some sleep. But CTile seems to be the biggest performance hit. (I did remove that line of code you told me I didn't have to call everytime, which makes alot of sense.)

Give me about 8 - 10 hours when I get home or wake up. :)

I've always had this issue with crm32pro, so it's nothing new. I'm not sure if I'm doing anything wrong, but using the default renderer for win xp using CTile to display about 13 x 11 tiles on the screen + two CRM32Pro_Ssprite sprites - the performance on an 800mhz pc 320mb mem., ati radeon 9600 pro is < ~20 fps with 800x600x32. At 800x600x16 the speed is upped maybe 5 to 10 fps. At 800x600x8 it's really good, but my gfx use their own palettes, up to 80 colors each so things like my text which use the color 4, 4, 4 get converted to 0, 0, 0 and therefore are transparent. I don't want to hack it and change the colorkey just to get a good frame rate on a bpp that's hardly ever used anymore. Plus for some reason it crashed really hard at 8bpp fullscreen, but doesn't at 16 or 32. (or 24, if its supported, I never tried it.)

I've optimized the tile display as far as I can, but I'm not sure how to up performance, oh and compiling as release has all kinds of nice issues. (CTile's don't display!!) Also, when I run the program compiled as debug from it's directory, nothing shows and it eventually quits out with no errors, no error info in the log file. When it's compiled as release the sprites show, but the CTiles don't, again no errors.

And I guess you know about this, but the directx renderer is either trying to access or free memory of an invalid pointer when it shuts down so I avoid using it, even though it is very fast.I will list the CTile display code, but i see nothing obviously wrong with it.

Código [Seleccionar] Expand


class Static_Layer
{
public:
Static_Layer(char* DPF, char* name, int size=256, bool repeat=false)
{
Tileset = new CRM32Pro_CTile();
if(!Tileset->Load(DPF, name))
return;

// set offset to the bottom of the layer of tiles
y_offset = (size - 11) << 6; // 6 = * 64
// set size of map in y coord amount of tiles.
y_size = size;
// if map scrolling repeats
y_repeat = repeat;

// log debug info
#ifdef _DEBUG
Test_Fill();

Tileset->Info();
#endif
}
~Static_Layer(void)
{
delete Tileset;
}

void Test_Fill(void)
{
// fill in some random tiles for ground
for(int x = 0; x < 13; ++x)
for(int y = 0; y < y_size; ++y)
{
// temp
data[x][y] = CRM32Pro.Rand() % 5 + 1;
}
}

void Do(float offspeed=1.0f)
{
if(!Tileset) return;

int x = 0;
int y = 0;
// draw the ground
for(x = 0; x < 13; ++x)
for(y = 0; y < 11; ++y)
{
// temp
// << (shl) is multiply
// >> (shr) is divide
Tileset->SetTileSet( 1, 64  );
int xpos = (x << 6);
int ypos = (y << 6) - (y_offset%64) - 32; // 32 pixel shift downwards
int tiley = (y+(y_offset >> 6));
int tile = data[x][tiley];
Tileset->SetPosition(xpos, ypos);
// check for error
if(tiley>0)
{
tiley = 999;
Tileset->Draw(0, data[x][0]);
}

// on-screen debug info - "yard lines"
#ifdef _DEBUG
if(x==12)
{
char* info = new char[43];
sprintf_s(info, 42, "[%i]", tiley);
Font->PutString(CRM32Pro.screen, xpos - 4, ypos, info);
delete info;
}
#endif
}

// on-screen debug info
#ifdef _DEBUG
char* info = new char[43];
sprintf_s(info, 42, "[Map_Layer First Tile = %i]", (y_offset>>6));
Font->PutString(CRM32Pro.screen, 1, 1, info);
sprintf_s(info, 42, "[Map_Layer Last Tile = %i]", y + (y_offset >> 6));
Font->PutString(CRM32Pro.screen, 1, 24, info);
sprintf_s(info, 42, "[Map_Layer.Y_Offset = %i]", y_offset);
Font->PutString(CRM32Pro.screen, 1, 48, info);
delete info;
#endif

y_offset -= (int)offspeed;
}

private:
CRM32Pro_CTile* Tileset;
// screen of 64x64 tiles WxH = 13 x 11
// max map size = 13 x 512
int data[13][512];
int y_size;
int y_offset;
bool y_repeat;
};