I might actually finish this one

Page 3/6
1 | 2 | | 4 | 5 | 6

By Bengalack

Master (192)

Bengalack's picture

26-09-2020, 10:34

Just a glimpse of the current WIP. Five months later and I have added some technical improvements and a few gameplay features.

https://youtu.be/NYzHc4tC2kk

"Apologize" for the theme used :D - it may give the wrong impression. It is only temporary - I hope to get graphics done by https://www.instagram.com/pandemonium_arts/

So, my challenge now is that there is NO audio in this piece of code. No effects, no music player - I have not decided on what to use, and I fear I have a timing issue added it, as the engine has already been changed from 60Hz to 50Hz :O

By Manuel

Ascended (16980)

Manuel's picture

26-09-2020, 10:54

How did you end up with sprite management?

By Bengalack

Master (192)

Bengalack's picture

26-09-2020, 11:05

Manuel wrote:

How did you end up with sprite management?

Wrt to sprites used for masking on the sides, I use 4 on each side, so 8 sprites are reserved for this. This gives the rest of the game 24 other sprites at any given time, which seems ok. I split the screen into 3 and just reassign the y-value for the 8 sprites a couple of times pr frame.

By Manuel

Ascended (16980)

Manuel's picture

26-09-2020, 11:45

Great solution! Looks really smooth ????

By wimpie3

Champion (318)

wimpie3's picture

26-09-2020, 11:56

Looking mighty good!

By santiontanon

Paragon (1093)

santiontanon's picture

26-09-2020, 12:44

Great progress!!! As for sound, how many CPU cycles do you have left more or less?

By Bengalack

Master (192)

Bengalack's picture

26-09-2020, 15:18

santiontanon wrote:

Great progress!!! As for sound, how many CPU cycles do you have left more or less?

Currently it's a bit hard to say how much time I have left, or, will have left, after further optimizations. I have some things that have a constant run-time that are run every frame (like the background scroll). But then there are two major cycle-hungry operations that makes this assessment hard:

1) tile-animations/movement (fire, moving platforms and similar)
2) sprite-animations/movement (exclude player-sprite, this one is handled separately and every frame)

Their runs are currently alternating every frame, and cpu-time is dependent on the content added in to the playfield. Obviously, the cpu-time varies here.

So, the playfield in the last video takes this into account, and at the most heavy place, I think I have around 32 scanlines available. I read a post by ARTRAG once, where he said that 192-lines on screen takes 43728 cycles, so that should give me 7288 cycles. Too little? I have an old FM-PAC-routine which I think I got down to 12000... I also loved the NOP MOD-player v2.0. Fantastic!!! - but the tunes I tested with easily went above 20000 at times :-O If the music routine does not have to be called every frame, that could help Smile

The time ahead will have to be spent on (aside from new gameplay features Smile) optimizing the code further:
1) mostly by converting C-code to asm. Right now gameplay-code is in C (sounds like an easy way to optimize, but most of this c-code is pretty optimized already with lots of pointer arithmetics, __fastcall to asm and other tricks, alongside some real good optimizations by the SDCC-compiler. I also have to use quite a bit of 16-bit coordinates which, of course, is slower).
2) possibly smarter handling of objects. Visible vs non-visible (sprites have this). I have to see what a typical playfield will look like in the end.
3) spread operations out across frames where possible.

By Bengalack

Master (192)

Bengalack's picture

26-09-2020, 15:19

and 4) test out @santiontanon's assembler optimizer! of course :-D

By Bodhi1969

Expert (76)

Bodhi1969's picture

26-09-2020, 20:44

Very nice work!

By ~mk~

Master (248)

~mk~'s picture

27-09-2020, 04:09

Mario meets Wonderboy! I say keep those graphics Smile

Page 3/6
1 | 2 | | 4 | 5 | 6