Page 4 of 5

Re: Do you need tutorials ?

Posted: Tue Dec 04, 2018 1:47 am
by Sik
If it ends up inside vblank it means you have lots of free time left so you wouldn't care anyway. But yeah, the method is not perfect (it doesn't play nice with raster effects either), an ideal method would involve a dedicated profiler (either in an emulator or somehow hooked up into real hardware). The HV counter is not perfect either as the V counter may repeat some values during vblank (once ended up with a game advancing too fast in PAL because it saw 224 twice… stopped using HV counter for framerate timing after that)

Note that your last remark is pointless, since slow down is noticeable (period), but the original question was about knowing how much CPU usage was left before slow down would kick in (and for that you need a more-or-less accurate measurement).

Re: Do you need tutorials ?

Posted: Tue Dec 04, 2018 5:51 am
by darkjoy2k2
so i think theres no other choice than just moving on
and see when the Genny starts to cry.

For now it works flawless in 50hz and 60hz mode on real hardware.

Anyway the checks are just made when really necessary,
for example:

Which tile are we? its a 94, 94 has a diagonal so lets check that.

an exclude of a certain area could really save some more time by partitioning, if you say MULS are bad...


Player approaching tile from Northwest...
0 is surely free to move. 1 is blocked for sure, so onyly if the player enters Areas X8Y0-X16Y8 or X0Y8 - X8Y16 the "evil" checks are needed.

If the partitioning goes down to its last bit, i gues the MUL really cound be circumvented, but its hard to believe that 300 lines of code more to execute this checks really sum up less than a one line calculation.

I dont have studies Informatics and so i dont know the inner workings of a CPU, least i know is that the old ones dont have "floationg points". For whatever that means... :-D


Mega Drive facts according to

Additions 639,000 adds/sec[n 6]
Multiplications 109,000 multiplies/sec
Divisions 54,000 divides/sec (16-bit)[n 12]

Re: Do you need tutorials ?

Posted: Wed Dec 05, 2018 12:31 am
by Miquel
mul's and diagonal colliding are two distinct subjects.
Sik wrote:
Tue Dec 04, 2018 1:47 am
since slow down is noticeable (period)
Can you spot when a game drops from a 60 f/s to 59 f/s just a second visually? Wow, you aren't human!

Do you belong to Ganimedes? perhaps Neptune? maybe Triton?... I know... you are from Geminis!

Just kidding! ;)

Re: Do you need tutorials ?

Posted: Wed Dec 05, 2018 8:08 am
by darkjoy2k2
Maybe the benchmark tutorial has some routines to check the load.

How else could it show a result?

Re: Do you need tutorials ?

Posted: Thu Dec 06, 2018 5:19 am
by Miquel
Usually ‘noticeable’ refers to the senses in English, something being perceived; that’s at least how I interpret it.

Re: Do you need tutorials ?

Posted: Thu Dec 06, 2018 3:36 pm
by darkjoy2k2
Totally agree...

you surely dont spot the "1 Frame missing".

But you play and you start to feel a kind of stuttering. Not much, but somethings wrong with the flow.

Like experiencing game on PC and looking at PS4/Xbox1 games afterwards :-D

Re: Do you need tutorials ?

Posted: Thu Dec 06, 2018 11:36 pm
by Miquel
Owh! really? Then just ask! What’s happening is, I suppose, that I’m so used to those affairs that I take some info as already known. What needs proper explanation?

Anyway, everything I said is true except Sik being from elsewhere, that was just a joke.

We are beginning to develop our own jokes related to other people, and now that you mention it, I recall people looking awkward when we do. For example, when I say “This has less future than a stripper on Neptune”, you don’t follow I presume.

Well the thing is, as far as I know, all intelligent species on Neptune go nude. We believe this is because dressing on water offers no advantages, there is no thermal conservation.

Furthermore, all civs we have found that live in water go naked on their natural habitat. But what makes this joke work is that this planet is only water based so we don’t expect to find dressed people there.

Re: Do you need tutorials ?

Posted: Fri Dec 28, 2018 8:42 pm
by babarricus
Hi everyone - long time lurker, first time poster here. :D I absolutely love playing around with SGDK, thank you so much Stef and all the experts on here for sharing so much excellent information.

I found these nice tutorials on someone else's website - ... ng-part-1/

Re: Do you need tutorials ?

Posted: Sat Dec 29, 2018 9:04 am
by Stef
Thanks :D
I plan to add more samples to SGDK, i think that is an easy and quick to get into what you need to know :) Writing tutorials is really time consuming, sample are easier to do ;)

Re: Do you need tutorials ?

Posted: Mon Jan 07, 2019 12:34 am
by kubilus1
So I've been working on a higher level 'engine' on top of base SGDK functionality for a bit. Implementing physics and sprite collision stuff ATM, so this is all pretty fresh in my mind. I found this pretty helpful: ... medev-6331

There are lots of little mistakes in the code, consider it pseudocode, but the general ideas are all there.

As others already have mentioned, the Genesis doesn't give us a lot of hardware help with sprite collisions, but it doesn't give us nothing either. For instance the VDP_SPRCOLLISION_FLAG will tell us if *somewhere* a sprite has collided or not.

Not terribly useful on it's own, but I'm playing with leveraging this just a tiny bit. For instance, if I check this during hblank, and note the VCOUNTER, I get some more info: What line a collision occurred. That's more handy, but I could have collisions on multiple lines.

So, what if I use that to set a flag based on the tile row a collision occurred. I could then have my sprite collision detection portion in the main loop simply AND a particular sprites row mask with this collision flag mask and pretty quickly determine if this is a potential sprite collision I would want to pursue more deeply. So far this seems to grant me some slightly better performance when I have lots of collisions happening.

Re: Do you need tutorials ?

Posted: Mon Jan 07, 2019 11:04 am
by Stef
Very interesting article ! thanks :)
About the collision, to be honest i'm not sure the sprite collision flag could be really useful.
At worst it can just tell you 'ok, there is 2 sprites colliding somewhere' but testing the flag at each line would eat too much CPU (even testing it each 8 lines would take some CPU time).
And you can't say "ok i will do my collision test code only if the sprite collision flag is set", otherwise the frame rate may be inconsistent if your collision test code is too heavy.. So anyway you have to make it fast enough to make it fit in a single frame, in which case you probably want to execute it for every frame.

Re: Do you need tutorials ?

Posted: Tue Jan 08, 2019 1:21 am
by kubilus1
So yeah, obviously we wouldn't want to do any kind of collision test within an hblank. That would be crazy slow.

But, we get what, 91 clock cycles per hblank. Assuming it's not used for something else, that ought to be enough time to save some info to use elsewhere. In my initial tests I'm doing something like the following:

Code: Select all

void hblank() {
        coll_row_mask |= 1U << (GET_VCOUNTER >> 3);
        spr_coll = 1;       
So far this alone is not effecting FPS.

I now have a coll_row_mask with flags I can check in my main loop and if I track the row a sprite is in as it moves up/down, I have a very quick method to weed out non-hits.

Will I keep this? Who knows, I might chuck it. My approach right now is just to see what I can leverage. Part of the fun of these old systems are the restrictions.

Re: Do you need tutorials ?

Posted: Wed Jan 09, 2019 12:16 am
by Miquel
Stef wrote:
Mon Jan 07, 2019 11:04 am
About the collision, to be honest i'm not sure the sprite collision flag could be really useful.
There is an awful lot of things wrong about using this flag. In fact, I don't understand why you put it in you kit at all.
Just for start, how do you id which characters are colliding?

Re: Do you need tutorials ?

Posted: Wed Jan 09, 2019 1:30 am
by kubilus1
Well, it can depend on your game logic, for one. For instance, let's say we are creating a tennis game with a player sprite on the bottom and a player sprite on the top. If we get a VDP_COLLISION and our ball sprite is over halfway up the screen, we know exactly where the collision occurred.

In other cases, it's an optimization.

Let's take for example a game where we have an arbitrary layout of 40 sprites. We could simply iterate through all our sprites and check boundry box against each boundry box, and run a collision handler whenever we have a collision. This is terribly slow, however. Keep in mind we may need to check 40 sprites against 39 sprites, one by one.

What if while we move our sprites around we indicate the row(s) the sprite is on. Now we could check fairly quickly by doing a logical AND against each sprite and relatively quickly determine if we need to check for a collision further or not. For some games, perhaps tile based games, we have an absolute row collision, and only even need to check for a column collision. However, depending on the number of sprites this still is fairly expensive, since we still are at least row checking 40 sprites against 39 sprites, one by one, regardless if there is any collision or not.

Let's say we note which row a potential collision occurs on, as I described in an earlier reply. We can now first check that a sprite on a row collides with *any* sprite before we check against each potential sprite by doing a simple logical AND of our sprite's row flags and the collision row flags we have set. We reduce the number of potential iterations significantly. In the no-collision case we are now down to 40 quick checks, total.

We can perhaps take this a bit further. Let's also preserve the VDP_COLLISION flag (recall it's unset as it's checked) and before we begin checking for any collisions in our main loop we check this first. By itself, this isn't much of an optimization. As sprites bang around our game they may overlap from last time, triggering this pretty much constantly.

However, what if, as we resolve our collisions, we have our game logic put each sprite into a no-collision state. Not all games, may be able to do this, but for certain ones, we could resolve the collision in a bounce, or a destroy, or whatever so that next frame, at least that sprite pair no longer collides.

This is at least my current thinking.

I'm playing with the idea of having object/sprites in a row based collision list so that I could get initial checks down to 32, but haven't gone down that rabbit hole yet.

Re: Do you need tutorials ?

Posted: Wed Jan 09, 2019 5:43 pm
by Miquel
kubilus1 wrote:
Wed Jan 09, 2019 1:30 am
we know exactly where the collision occurred.
No, you don't. You only know that in a line graphical sprites overlap, nothing more. And that's after losing about 50% of the cpu.

Anyway, if you are sure just do it. We learn more from our failures than from our success, so it’s a win/win, don’t worry.