Metal Blast 2277 - Sega Genesis / Mega Drive - FREE release!

[Sik]

Well, ABCD uses carry so you can concatenate multiple of them easily to do larger numbers... May want to add those values in RAM to make this easier (otherwise you need to use many rotations which is slow). At least it should be faster than the approach there (in terms of cycles).

Dividing would be the obvious easy option, the big issue is 32-bit division (which you'd need for large digit counts)... there are more specialized algorithms for this purpose, although they need large look-up tables if you mind the ROM space usage.

[mix256]

Well, ABCD uses carry so you can concatenate multiple of them easily to do larger numbers... May want to add those values in RAM to make this easier (otherwise you need to use many rotations which is slow). At least it should be faster than the approach there (in terms of cycles).

Dividing would be the obvious easy option, the big issue is 32-bit division (which you'd need for large digit counts)... there are more specialized algorithms for this purpose, although they need large look-up tables if you mind the ROM space usage.

Yeah, come to think of it, how often do you actually score (pre-pubertal pun not intended) per frame.

So "having the BCD-add X times and then a cheap print" vs "having X easy u32 adds and then a complex print".
If X is 1...which is the normal case, unless you fire off some smart bomb or something, then we won't be gaining much.
So, once again, I do premature optimization.

Don't want to hijack SegaTims thread with this, though, so sorry SegaTim!

[Stef]

Exactly, BCD operations are never a bottleneck in a game as you rarely need it more than once per frame...

[Miquel]

Well, ABCD uses carry so you can concatenate multiple of them easily to do larger numbers... May want to add those values in RAM to make this easier (otherwise you need to use many rotations which is slow). At least it should be faster than the approach there (in terms of cycles).

Timing of rotations/shifts is depended of the arguments, for example (talking about register operations):
x << n will take 2+n*2 cycles
So x<<2 will be 6 cycles, and x<<3 will be 8 cycles.

Not that much really.

Note: [To anyone] I'm speaking from memory, if I'm wrong about the cycles tell me so but not crush my skull. Thanks.

[Sik]

I was thinking of 8-bit rotation on two long values which is 48 cycles in total (24*2) and you'd need to do it for every extra pair of digits in addition to another ABCD... doing it from memory directly is faster than that, besides requiring less instructions (and hence being simpler to understand).

Also you got the cycle count right for byte/word (add 2 more cycles for long).

[SegaTim]

New video - https://viuly.io/video/wip-project-c--- ... 55a8963767

[mix256]

But now you must have some of the palms as sprites, right?

[cero]

Reminds me more than a bit of Duke Nukem 1.

[SegaTim]

But now you must have some of the palms as sprites, right?

Everything was so conceived.

[Chilly Willy]

Reminds me more than a bit of Duke Nukem 1.

Yeah, it sure does. It's coming along nicely. Nice parallax effects.

[SegaTim]

Work in progress. New screenshots:

[SegaTim]

Work in progress...

New video - https://youtu.be/cs615CozC8k

[Chilly Willy]

Cool more action. The platform part is still a bit... sharp. You might want to round off the edges of the ground a bit... break up the stark up-down nature of the level a little. It doesn't seem natural.

[SegaTim]

Cool more action. The platform part is still a bit... sharp. You might want to round off the edges of the ground a bit... break up the stark up-down nature of the level a little. It doesn't seem natural.

This is normal?:

[Chilly Willy]

That's a little better, but what I was thinking was more along the lines of what you see in Rayman in the first area. Not exactly the same thing, but more like it. Or like some of the zones in Sonic. That's probably a better example than Rayman.