For quite a while now I have been thinking of doing an isometric title for the Lynx since
(at the time!) it seems like the ideal plattform for this with SUSY's fast bitmap drawing etc.
A couple of weeks ago Dan Thoresen started posting some mockup screens of a hypothetical RPG style isometric game.
Recently he started implementing it for the hypothetical hardware plattform Pico8 
I was in awe und since he sent me his original spritesheets with the tiles I started testing how this would work and look on the Lynx.
I would not post here if I wasnt determined to develop this into a full scale Atari Lynx game. Ever since we are inclose contact on this endeavor and Dan was most helpful and we had some great chats on layout and general issues.
The maps are 10x10 with the outer tiles usually being defined as (back)walls or exits/doors.
My first proof of concept would draw all 10x10 tiles sorted by z-position in a long 100 sprite chain each frame.
Then go on with the player, items and the doors in case they are located at the south/east sides.
It turned out that this is about twice as fast in handysdl or mednafen than on real hardware. What a bummer ;-(
Setting the skip-this-sprite flag was roughly about as fast as pointing the data to a 1 pixel transparent sprite.
Drawing isometric tiles is somewhat tricky as i.e. walls are not at the center of a tile but instead are shifted to one side.
Outward corners hence require two tiles to be drawn at the same position, something a Sprite-chain for SUSY couldnt easily reflect.
There is no simple way to redraw individual tiles (quickly) as for isometric view you never know in advance which tiles will overdraw what areas unlike for top-view set ups.
Also the conversion map-position, tile-position and screen x,y coordinates can get a bit tedious.
During the weekend I decided to drop the draw-all-tiles each (2nd, 3rd..) frame and instead went for the classic approach to handle this in software via CPU.
So still all 100 tiles are checked for subterrain structure, then all 100 tiles are plotted but that only happens once per room change.
Only the player and the objects in the room (much less than 100) are drawn each (double buffered) frame.
When the player (or other movable objects later on) are being drawn, the data beneath the player gfx is buffered and restored before the player gets drawn at another position. This happens each frame.
To allow the player to walk in front of objects as well as behind them I parse the list of items and replace the next_in_chain pointer of the object that is just being further away then the player by the sprite data for the player itself.
The player sprite definition points again back to chain and continues to draw all objects in front. The player sort of gets injected into the ONE sprite chain SUZY is drawing.
Despite all the buffering and restoring of bitmap data and pointers this is much faster now and I am more than happy with the overall result.
It is still in a pretty early stage but I think there are no further showstoppers now that the engine runs fast enough (with quite some raster time left).
The numbers on screen show the amount of raster lines used after start, after the player sprite is buffered and the data injected, after some minor pointer changes (just 1 line currently) and after all of the items including the player are being drawn. 0x16 = 22 rasterlines including some dummy IRQ placeholder in handy_sdl.
Not yet verified on real Lynx but even if a factor 2 applies again, I feel fine.
If there is interest, I will happily keep posting here on the progress.
Cheers,
Martin /enthusi & Dan
Edit:
Igor of Atarigamer.com wrote a small article on "Lacim's Legacy":
https://atarigamer.c...-for-atari-lynx
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube