42bs Posted September 17, 2019 Author Share Posted September 17, 2019 I find partly redrawing difficult if you use double buffering. But if only a few tiles change per game cycle then you can go for 60fps and can do w/o double buffering. Quote Link to comment Share on other sites More sharing options...
Nop90 Posted September 17, 2019 Share Posted September 17, 2019 In Xump I do double buffering and udate only the changed tiles: I do it with a two step update (I keep track of the previous frame changes and of the ones for the current frame). 1 Quote Link to comment Share on other sites More sharing options...
enthusi Posted September 19, 2019 Share Posted September 19, 2019 (edited) This is one of my early attempts to use chains when I started getting into Lynx. LOTS OF THEM. More than 300 in this case. The sprites mimic C64 characters and are a mere 8x8 pixel in size. The screen scrolls in pixel steps. Press Button A or B while moving for faster scrolling. The map is quite large! It consists of (iirc) 96x85 tiles. Each tile is 32x32 pixel large and consists of 4x4 characters a 8x8 pixel. The full level is 3072 x 2720 pixel large and stored as those aforementioned pointers into pointers into pointers and thus fits into those few KBs of this unpacked binary. turrican.o Edited September 19, 2019 by enthusi 2 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted September 19, 2019 Share Posted September 19, 2019 Long day doing automation test debugging so my brain is melting... what would be the benefit of this approach? More modularity with the tileset blocks? Or am i missing something? Quote Link to comment Share on other sites More sharing options...
enthusi Posted September 20, 2019 Share Posted September 20, 2019 (edited) Size and variety are the main drivers here. The map is 3072 x 2208. That are 420 full Lynx screens! Stored in ~30 KB. The full map (fullscreen attachment) consists of 32x32 tiles. But WAY too many of them to store those as sprites, either (see 2nd attachment). Those 32x32 tiles again are constructed out of 4x4 tiles with 8x8 pixel size each. And of those we only have 180 or so. THAT fits easily into memory. Of course it is an effort to make such graphics. Those were made on C64. Only very few games really tried HARD on the Atari Lynx to max out its specs in my opinion. This is quite common for any plattform with such limited commercial lifetime. I hope we will see in the time to come what this beast is really capable of. WITHOUT cheating by giving it more power or larger carts that it ever had. The last shot shows the 32x32 tiles in the full screen map. Edited September 20, 2019 by enthusi 1 3 Quote Link to comment Share on other sites More sharing options...
42bs Posted September 20, 2019 Author Share Posted September 20, 2019 But you are not chaining all tiles, right? Even though Suzy can clip, the x/y position should not exceed 511, else you get a notably slowdown. Quote Link to comment Share on other sites More sharing options...
enthusi Posted September 20, 2019 Share Posted September 20, 2019 No, obviously not! I only chain enough sprites to draw a fully visible screen + one 4x4 tile to the right and bottom (it is not optimized as this were really by first footsteps :). Ideally you only draw 8 pixel into the right and bottom border, not 32 So the screen is 192x160 or so. ~ 432 sprites or in the range of that. I wrote a routine to update all points of the sprite-chain once we move by more than 1 tile. Quote Link to comment Share on other sites More sharing options...
LordKraken Posted September 20, 2019 Share Posted September 20, 2019 Quote the x/y position should not exceed 511 What is exactly this 511? (I love magic values and this one sure looks like one :D) What actually happen if you have a sprite on x=512 ? Also in BLL, how does that impact the use of hoff/voff ? Quote Link to comment Share on other sites More sharing options...
42bs Posted September 20, 2019 Author Share Posted September 20, 2019 Sprite drawing slows down. Maybe not the position (long time ago that I tested it). But for sure the size. You can draw a sprite 300x300 and move it with hoff/voff. Suzy does the clipping and I did not see any impact. But if the sprite exceeds the 512 (height or width) then drawing slows down. 1 Quote Link to comment Share on other sites More sharing options...
42bs Posted September 20, 2019 Author Share Posted September 20, 2019 29 minutes ago, enthusi said: No, obviously not! I only chain enough sprites to draw a fully visible screen + one 4x4 tile to the right and bottom (it is not optimized as this were really by first footsteps :). Ideally you only draw 8 pixel into the right and bottom border, not 32 So the screen is 192x160 or so. ~ 432 sprites or in the range of that. I wrote a routine to update all points of the sprite-chain once we move by more than 1 tile. So pixel move with hoff/voff until the edge of the tile and then update the chain for the new set?! Wow! 1 Quote Link to comment Share on other sites More sharing options...
enthusi Posted September 20, 2019 Share Posted September 20, 2019 Yes, exactly like that. Even that is fast enough (just for scrolling at least ;-). 8x8 really isnt well suited for Lynx but this is just a demo. Quote Link to comment Share on other sites More sharing options...
+karri Posted September 20, 2019 Share Posted September 20, 2019 OMG. I will re-write On Duty to work like that just to see if I get the character moves smoother. In On Duty I use 16 by 16 sprites and I do the hoff/voff in software instead of using these registers. It would be nice to see if there is some speed advantage I could gain by using linked sprites and hoff/voff. 1 Quote Link to comment Share on other sites More sharing options...
LordKraken Posted September 20, 2019 Share Posted September 20, 2019 Quote Sprite drawing slows down. Maybe not the position (long time ago that I tested it). But for sure the size. I support "neverending" scrolling images in the inside world and havent seen any fps drop when I go over 500 or more. So yeah that's probably the sprite size that matters Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.