Jump to content
IGNORED

A8 Sprite Multiplexer in 2022?


Recommended Posts

Hey Guz,

 

Taking inspiration from https://playermissile.com/dli_tutorial/, I implemented vertical sprite multiplexing in 8bit-Unity last year.

However the performance is less than ideal in my new game "8bit-Strike". I still get excessive flicker when more than 2 multicolor sprites share the same DLIs.

 

I have seen some pretty impressive stuff on this forum (Like this: http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM).So I wonder if anyone could point me in the direction of the "ultimate" sprite multiplexer in 2022? Something that does both horizontal and vertical multiplexing, with minimum use of CPU cycle....

 

Thanks in advance!

  • Like 1
Link to comment
Share on other sites

41 minutes ago, 8bit-Dude said:

Hey Guz,

 

Taking inspiration from https://playermissile.com/dli_tutorial/, I implemented vertical sprite multiplexing in 8bit-Unity last year.

However the performance is less than ideal in my new game "8bit-Strike". I still get excessive flicker when more than 2 multicolor sprites share the same DLIs.

 

I have seen some pretty impressive stuff on this forum (Like this: http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM).So I wonder if anyone could point me in the direction of the "ultimate" sprite multiplexer in 2022? Something that does both horizontal and vertical multiplexing, with minimum use of CPU cycle....

 

Thanks in advance!

It sounds like you are looking for a general-purpose library (or routine) to handle the sprite multiplexing, but you are going to find that the only general-purpose implementations will lead to the flickering you have now.  A flicker-free multiplexor will need to be designed around your specific game, with clever in-game constraints allowing you to reuse the same players/missiles on different scan lines.   

  • Like 1
Link to comment
Share on other sites

Not sure if this helps, wrote it some time ago just to see how many sprites I could get on screen (64 I think)

no vertical movement, but same sprite being displayed multiple times on different scan lines.

All the calculations are done during VBlank processing, so the DLI just picks up the new offsets

for each sprite. Give it a few seconds to get going and you will see them split.

 

Code itself is a bit of a jungle, but I did this just because I could :)

 

PLAYER.XEX

  • Like 2
Link to comment
Share on other sites

10 hours ago, TGB1718 said:

Not sure if this helps, wrote it some time ago just to see how many sprites I could get on screen (64 I think)

no vertical movement, but same sprite being displayed multiple times on different scan lines.

All the calculations are done during VBlank processing, so the DLI just picks up the new offsets

for each sprite. Give it a few seconds to get going and you will see them split.

This is more or less what I already implemented: re-use of Players in the vertical direction (by updating the XPOS and COLOR on DLI lines).

Link to comment
Share on other sites

12 hours ago, mellis said:

It sounds like you are looking for a general-purpose library (or routine) to handle the sprite multiplexing, but you are going to find that the only general-purpose implementations will lead to the flickering you have now.  A flicker-free multiplexor will need to be designed around your specific game, with clever in-game constraints allowing you to reuse the same players/missiles on different scan lines.   

The example which I posted (http://atariarea.krap.pl/24h/spritemania/STRSPLXR.COM) is close to what I would like to achieve.
Are there code snippets out there showing how this wizardy was achieved?

Link to comment
Share on other sites

9 hours ago, MrFish said:

 

I think this is the more developed version of the multiplexer above. There's a thread about it here (or in the main forum) somewhere; but here are the files.

 

 

 

Thanks very much Mr. Fish! I will study and see how I could integrate the engine into 8bit-Unity (some rewriting is probably needed, looks like some macros in there are not supported by ca65).

Link to comment
Share on other sites

4 hours ago, 8bit-Dude said:

But I had never heard of the "MIC" image file format before.

MIC is just a dump of ANTIC screen memory data, usually 7680, 9600 or 11520 bytes, the last 4-bytes are colors (712, 708, 709, 710).

A simple tool that works with MIC files is in the archive attached to this post in AdventureStudio/tools/gfx_slicer_src

 

Edited by ilmenit
Link to comment
Share on other sites

Alright, after playing around with this for a while, I now understand how the engine can be so fast.

Instead of just storing the sprite bytes and transferring them by indirect addressing, it relies on lists of immediate loads (like lda #0) followed by absolute,X stores (like sta $C600+0,x). This saves quite a bunch of cycles when setting the sprites, but..... it takes up a huge load of memory. Especially because the instructions are repeated twice (for PMG 0/1 and 2/3). Each sprite takes up about 6~8 times more memory space.

I won't be able to use the engine for 8bit-Strike, as I have 112 x 8 x 16 multicolor sprites (that would take about 28K of memory instead of 3.5K currently).

Link to comment
Share on other sites

5 hours ago, _The Doctor__ said:

24k left for all kinds of fun, you can do it!

No I cannot. This games needs about 10K for the charset/tileset/charmap, about 5K for network code, and so on...
I was already closed to maxxed out with the current implementation.

 

I might perhaps try to generate those immediate loads / indirect addressing code blocks when setting the sprite.

Link to comment
Share on other sites

Just now, 8bit-Dude said:

Of course, but then the game would only work on the XE!

And memory expanded computers.

Nowadays many enthusiasts have memory expansions, to enjoy some games (Prince of Persia, Stunt Car Racer to name a few) and many demos.

I think people buying online devices like 8bit-hub are enthusiasts, not basic users, therefore I would think about using 128KB, if that avoids flickering.

Link to comment
Share on other sites

5 hours ago, Philsan said:

And memory expanded computers.

Nowadays many enthusiasts have memory expansions, to enjoy some games (Prince of Persia, Stunt Car Racer to name a few) and many demos.

I think people buying online devices like 8bit-hub are enthusiasts, not basic users, therefore I would think about using 128KB, if that avoids flickering.

@Philsan  @8bit-Dude  - I'd agree you with you Philsan regarding memory expansions and I'd hazzard an educated guess that we are talking about enthusiasts more than basic users in the above instance.

 

In fact I'd go one step further to say that if as an retro computer owner you are regularly playing on/supporting a retro computing platform like ours 3-4 decades after the platform officially stop being mainstream - I'd class the majority of A8 owners as enthusiasts by definition. Certainly that is the case on AA as far as I can tell.

 

On a related note one of the reasons I started my A8 RAM poll here last month - to guage the "rough" landscape of A8 owners with regards to the stock machine RAM range (16k through 128k) and 256K and upwards RAM A8s - was to see how many owners have A8s of over 256K of RAM. This was with game developers in mind.

 

The poll's trend showed two numbers standing out, *not unsurprisingly showing a high number of owners having both a 64K A8 as well as an upgraded A8 of 256k or more. (Of course the poll is only a snippet and isn't without flaws/interpretation, and as such is a rough indicator - but nevertheless I find it very compelling:)).

 

See here and the number for 256k and above A8s is only slightly trailing behind the 64K A8 figure:

 

image.thumb.png.d5cd5a740d7863d4dae9c540e054696b.png

 

*I say not unsurprisingly because 256K, 320K, and 576K upgrades have been around for decades an have been installed by many. Some of those machines have then been sold on and recirculated within the community. (More recently of course the U1MB and similar sized 1088K upgrades have been becoming more popular.)

 

Interestingly still a good amount of the 101 owners who completed the poll own a 128K machine. So to also have such a high number of people in the poll having both 64K and 256K or higher machines is very encouraging IMHO and hopefully helpful to those creating games for the platform.

 

Whilst I totally get why anyone coding and creating games and software for our beloved platform would ideally wish to code for 64K, I think given a lot of Atarians own higher RAM A8s than one might first assume/was generally thought the case, 128K is still a totally viable RAM size to code for and still have a significant audience. 

 

Globe, (creator of the amazing Final Assault 3D raycasting game), amazingly crammed that game into 64K which is fantastic. (I also totally get the personal challenge that comes to a coder wanting to cram it into 64K as well).

However his next engine by all acounts is promsing to be amazing and is targeted for 128K RAM A8s which is already looking something special and is improving greatly on Final Assault's engine as a result.

At 128k still a significant amount of A8 owners will enjoy it because they don't apper to just own one 64K machines. (Again I am going on the trend there - I know the poll is only a snippet:grin:).

 

Anyways - going off on a tangent for this thread so apologies.

 

Great work 8bit-dude and thanks for supporting the A8.:)

 

Edited by Beeblebrox
  • Like 1
  • Thanks 2
Link to comment
Share on other sites

In 1986-ish my dad gave me my very first 800XL.  He had already installed a 256K Rambo expansion in it.  However, I've spent most of my life waiting for games which actually support it.

I guess all I'm saying is, even BITD there were a decent amount of people with memory-expanded machines.  Today if you can read this forum you probably have the ability to run whatever you want on an emulator even if you don't physically own an upgraded Atari.  So you're really only excluding the few who insist on only running everything on unmodified original HW, no exceptions.

  • Like 2
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...