SpritesMind.Net

and just check if Overlap is true right? it doesn't seem to work for me though. btw I'm using it with the sonic example. This is how I do it: bool bColision = false; if( ! ( (pActor->boundingBox.left.integer > pActor2Test->boundingBox.right.integer) || (pActor->boundingBox.right.integer < pActor2Te...

First of all collision means detecting if two sprites/objects/entities are overlapping, since you question is that general perhaps you are adding other issues. Usually in 16bits you have two types of collisions: A) one sprite with another sprite B) one sprite with the ground (tiles) To solve A you j...

They are almost the same, aren't they? Just 1st routine has one more instruction (then slower), or am I missing something? Anyway, the fastest way to do something is not doing it. In this case you can have duplicate values: one in binary, the other in a kind of bcd form, and make the same operations...

Perhaps you should concentrate more on the game itself, and no so much on the external details. A game can change a lot during its development and could render outdated the other parts.

Take it just as a friendly advise.

I already ported the java code to C++, if somebody wants it I can post it here. What I'm going to do is limit the size of decompressed buffer to 4KB, create a buffer of that size on RAM, decompress each frame at least 32bytes and upload that tile thought DMA on vblank. That will be enough to keep ha...

Unfortunately you need to simulate/emulate/execute the code to analyze it: there are loops and they are the hot zones, and you can't detect it with a simple parser. I don't have recollection of a time when really maters to optimize a non-loop code. Still more there are instructions timing that depen...

Thanks Stef, the reason I want the code to be in C++ is because I have a tool that builds/compiles all the resources, so I just want to integrate it to that code/program; and perhaps later I will customize the compressor too. First, as soon as I have time I will convert it to c and play a little bit...

What I'm looking for is decompression while in game, then I need something very light. Currently this game is a vertical shooter at 60hz with up to 30/40 objects on screen, so no much cpu left.

It was badly rephrased on my part. I meant that since there are several inputs, instead of trying to combine them, on later stages, into a single input trying to guess how is gonna work later, just store them into several variables with the same meaning (or structure) but different content (data) as...

Stef, you don't have to code anything, I only want to know if it's doable. For example, I didn't thought of the possibility of reusing the decompressed buffer, as you mentioned. To simplify the problem, I'm going to use a permanent 4KB buffer on MD RAM and limit any compressed buffer, on ROM, to tha...

LZ4W cannot do random access but in fact it does perform not too bad for small chunk of data. For instance you can do chunk of 1KB (32 tiles), it should take about 1/10th of the frame time to unpack it, and about 1/7th of available frame DMA bandwidth to transfer it. No, I mean decompress it sequen...

I really wanted to provide a *very fast* unpacker in SGDK to allow live sprite data unpacking . ¿ Is there a way to compress about 128 or 256 tiles in a file (or buffer), but then decompress just a few each frame, like from 1 to 15 tiles per frame. So it has nearly no impact on cpu frame performanc...

You are correct, in fact if you are developing for NTSC you may only need planes as big as 64x32 tiles, 64x64 in case of PAL. Important things to keep in mind: - Speed of scroll (how many tiles per frame at most) - You can show partial tiles, so is no longer 320/8 x 224/8 tiles only, but at least 2 ...

You may introduce button presses and frame counter to the formula, that should work on emus. Also using the full register, H and V counter, should make a difference.

"Serious" games usually use fixed points instead of floating points in game logic because they are way faster. You should use them for things like "position" and "speed", there is a notable difference in response. The big handicap is you no longer have so many decimals, but is strange to use them in...