Supaplex graphical weird thing
Posted: Mon Oct 05, 2020 9:58 pm
- sp_bug_step_1.png (187.29 KiB) Viewed 2601 times
- sp_bug_step_2.png (186.96 KiB) Viewed 2601 times
- sp_bug_step_3.png (191.33 KiB) Viewed 2601 times
Rocks'n'Diamonds
Talk and discussions around the game "Rocks'n'Diamonds".
https://www.artsoft.org/forum/
Supaplex graphical weird thing
Page 1 of 1
Re: Supaplex graphical weird thing
Posted: Tue Oct 06, 2020 9:27 pm
This is what the above screen cast shows:
So the question is about that zonk being pushed when Murphy explodes, removing the right part of the zonk, while the left part stays in the playfield...
So the question is about that zonk being pushed when Murphy explodes, removing the right part of the zonk, while the left part stays in the playfield...
Re: Supaplex graphical weird thing
Posted: Tue Oct 06, 2020 9:53 pm
And here is the answer to your question, just tested with original Supaplex ("SPFIX63.EXE") in DOSBOX:
So, yes, it really occurs exactly that way in original Supaplex.
- sp_dosbox.png (29.25 KiB) Viewed 2599 times
Re: Supaplex graphical weird thing
Posted: Tue Oct 06, 2020 10:27 pm
Oh, I thought so. Thanks very much 
Sorry for sharing the links instead of presenting the problem in a text / picture form. I see you take screenshots of my videos whereby I busy you... Sorry again 
Sorry for sharing the links instead of presenting the problem in a text / picture form. I see you take screenshots of my videos whereby I busy you... Sorry again Re: Supaplex graphical weird thing
Posted: Tue Oct 06, 2020 11:01 pm
No problem -- just thought it would be faster and easier to read and understand for other forum users.
BTW, there are quite a number of such flaws or quirks in the Supaplex game engine -- R'n'D implements them all exactly like in the original game, as the engine code is a 1:1 representation of the original assembler code of the original Supaplex (well, the improved Speed Fix 6.3+ by Herman Perk), translated from x86 assembler to VisualBasic for Megaplex by Frank Schindler, and finally transcoded from VisualBasic to C using a little Perl script...
The reason for all these quirks is the fact that the Supaplex game engine is an "asynchronous" game engine (just like the R'n'D game engine itself), generally allowing for game elements to exist at different "in-between movement positions", while other game engines (like the Emerald Mine game engine) are synchronous, so all objects always move at the same movement position (in fact, they snap from one tile to the next, with a delay between jumping from one tile to the next, during that a movement animation is displayed -- but the objects are technically always either on the first or the next tile, never in between).
BTW, there are quite a number of such flaws or quirks in the Supaplex game engine -- R'n'D implements them all exactly like in the original game, as the engine code is a 1:1 representation of the original assembler code of the original Supaplex (well, the improved Speed Fix 6.3+ by Herman Perk), translated from x86 assembler to VisualBasic for Megaplex by Frank Schindler, and finally transcoded from VisualBasic to C using a little Perl script...
The reason for all these quirks is the fact that the Supaplex game engine is an "asynchronous" game engine (just like the R'n'D game engine itself), generally allowing for game elements to exist at different "in-between movement positions", while other game engines (like the Emerald Mine game engine) are synchronous, so all objects always move at the same movement position (in fact, they snap from one tile to the next, with a delay between jumping from one tile to the next, during that a movement animation is displayed -- but the objects are technically always either on the first or the next tile, never in between).