If I understood well, there is no way to work around this issue. I have to program for the worst case (Turbo R)... Not an easy task as I'm too close of the limit of the CPU, and still have more things to implement, such as music.
I would only worry about it when you actually hit the limit . Then you have a more complete picture of what can be optimised.
New version!
Video:
https://youtu.be/dcibKzg89l8
- 2 new enemies (there are 2 more, but I ran out of space on table sprite, need to create a logic to load them on demand). These new enemies use a new approach, they are made only of sprites (3 sprites, with no more than 2 per line). The previous enemies are made of tiles + one sprite, to make it possible two per line (plus the two sprites of the penguin), but they are too heavy on CPU usage and their use will be more limited than I wanted. As the new enemies are lighter on CPU is possible to have 4 on the same screen. Now I have two kinds of enemies, each of them with its own pros and cons;
- Smooth jump, with a table of pre-calculated delta-Y values (Thanks @theNestruo);
- Many bug fixes/refactoring, as usual;
- Testing a nice effect of blinking on Score (cycling 5 colors). Maybe I will make it blink each time it gets updated.
Hope you like it!
Happy to see the project progress.
Love it. Always nice to see things progressing like this.
Good work! Something is not "right" with the jump though. Doesn't look natural to me.
Smooth jump, with a table of pre-calculated delta-Y values (Thanks @theNestruo)
Good work! Something is not "right" with the jump though. Doesn't look natural to me.
Hi, albs_br! It seems that you are switching from jumping to falling on the first delta-Y = 0 of the table. If you keep all the 0s before starting to fall, the jump arc will feel better and look more natural.
Smooth jump, with a table of pre-calculated delta-Y values (Thanks @theNestruo)
Good work! Something is not "right" with the jump though. Doesn't look natural to me.
Hi, albs_br! It seems that you are switching from jumping to falling on the first delta-Y = 0 of the table. If you keep all the 0s before starting to fall, the jump arc will feel better and look more natural.
No, it's not. There are six '0's on the table and they are indeed being used. This may be confirmed by using "advance frame" feature of Emulicious.
JUMP_DELTA_Y_TABLE: ; jump height: 40 pixels db -4, -4, -4, -4, -4, -4 ; 24 pixels db -2, -2, -2, -2, -2, -2, -2, -2 ; 16 pixels db -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 ; 16 pixels .TOP_OFFSET_ADDR: db 0, 0, 0, 0, 0, 0 .FALL_OFFSET_ADDR: db 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 db 2, 2, 2, 2, 2, 2, 2, 2 db 4 .end:
I remember there were more '0's and the jump was strange (the player seems to "float" in the air). Maybe some further small adjust here will be needed.
If you ask me it looks like in the jumping curve on the fall there is an a sudden velocity change like an invisible hand pushing the character down. Almost a “stomp” move.
No, it's not. There are six '0's on the table and they are indeed being used. This may be confirmed by using "advance frame" feature of Emulicious.
(...)
I remember there were more '0's and the jump was strange (the player seems to "float" in the air). Maybe some further small adjust here will be needed.
Oh, I see... As there are fewer 0s than -1s and 1s, the direction change is too quick.
As you are using way more values than I did (like 3 times more), try interleaving them for smoothness. Something like this: ... -1 -1 -1 -1 -1 0 -1 -1 0 0 -1 0 0 0 0 0 0 1 0 0 1 1 0 1 1 1 1 1 2 ...
. Not an accurate example; just the general idea; kind of "dithering" the values.
If you ask me it looks like in the jumping curve on the fall there is an a sudden velocity change like an invisible hand pushing the character down. Almost a “stomp” move.
Indeed the transition from -2 to -4 was sudden. I changed the table and added some -3 steps.