Funny fact, the most powerful Sprite-System was available in the ET6000 from Tseng. Basically it used some kind of copper list like the Amiga but the list itself could also include overlay-data - and if you used it correctly you could display hundreds of sprites per line and each line with new data. The sprites could have any geometry, any colour depth and any position as long as the display-list didn't get too long for that line. There was a ET6000 specific Linux-Demo which used two 15Bit Playfields with 6Bit Alpha-Channel and in addition over 2000 sprites on display by literally using 0% CPU power. Surely nobody ever used all these insane features because back then graphics meant 320x200 at 256 colours by VGA standard. Nobody ever used the graphic chips to their full potential.

@agpxnet

5 ай бұрын

Oh I didn't know, too bad it wasn't exploited!

@bangerbangerbro

4 ай бұрын

I had dreamed of a system for a while that depended only on a copper changing background bitmap read address and colour palette address. Transparency seemed like the main problem. I didn't know of this system, it always seemed that the Amiga was the only system using this technique within a scanline. I'll have to look up this machine. Is it part of a PC video card then?

@thomasdoktor9497

4 ай бұрын

@@bangerbangerbro Yes, I had a video card (STB Lightspeed 128) with an ET6000 video chip for my PC, I remember it as a very powerful 2D card for its time with excellent support for video display, as it had MPEG-1 hardware acceleration. I paired it with a Voodoo card for 3D acceleration.

Excellent video. This is probably the best explanation of sprite multiplexing I have seen.

Can't be doing with the computer-generated speech, sorry - decent subtitles or a real human please!

@kreuner11

4 ай бұрын

Press the cc or subtitle button

Hello. I have always been curious about the effect of opening the side frames. you make cool visualizations. which allows me to better understand how something is made. Regards.

@agpxnet

5 ай бұрын

Maybe I'll make a video on this topic, thanks for the suggestions which are always welcome.

@riwilo

4 ай бұрын

Are you familiar how opening the upper and lower border is done? Opening the side border works in a similar way, but is harder. It requires a stable interrupt with no jitter and you have to manipulate the screen width ($d016) twice each raster line where you want to have the side border opened. Another hurlde are the badlines that occur. When this happens you only have 23 clock cycles left to open open the border, minus the clock cycles the sprites steal from the VIC themselves, which leaves you being able to display 4 sprites at most. A pretty good display of effectively using the side border is the C64 demo Memento Mori, which I recommend to watch.

Wow, great job on this multiplexer, omg, that is so well explained that it made it simple to understand. Also nice demos :D

Awesome explanation keep up these videos coming... you have unlocked my learning skills for 3 decades.

@agpxnet

5 ай бұрын

Thanks, whether I can make other videos will depend on the success and interest of these videos. Please, subscribe and share the link 😉

@PJBonoVox

5 ай бұрын

​@@agpxnetI'd be more than happy to do the English voiceover for future videos if you'd like.

The TTS voice is jarring, but good explanation!

@agpxnet

5 ай бұрын

Sorry, but it's the best free TTS system I've found. I'll see if I can find another better voice.

Exceptionally well done, in particular the awesome visualization. 👍

I remember theorizing about multiplexing while I owned my C64 as a kid but never got the chance to try and implement it. I didn't know if any game I could write would have enough speed to attempt it either. But my tools were as crude as my understanding, and self written too, so I can't be too hard on myself

Great explanation and demos!

Did not take me long to Like Sub and turn Notifications On. This is excellent !

So well explained. Well done sir!

Just saw people complaining about the voice. I thought that was you talking. It is so clearly spoken that i was wondering, haha... Good explained. Thanks for all the info, appreciate. I started like 2 months with assembly language using C128 (as C128, not C64) and will try to experiment a bit with your information. I am far away from your knowledge, but assembly is fun nevertheless. It is just, I am only 4 decades behind, hahaha... Happy new year soon, all the best wishes!

Nice! I'm working on my own sprite multiplexer, so this is a useful reference for me

Very thorough explanation. My own implementation is pretty similar except the collision detection. I precalculate which sprites have any chance as all of collision during sort, and check hardware collision on those. It can happen collisions are missed but generally next frame they still happen. Your solution is more precise but takes quite some cycles. I think the best solution depends on the use case. Good video, you got a sub!. Also the tts isn't that bad, Italian English is quite wild lol 🤣👍🏼

@agpxnet

5 ай бұрын

Hi, thinking about it I had also come to the conclusion that it would be possible to test for collisions with the hardware register, since if they hit they probably end up in the same group and therefore I could report the fact that it collided. Maybe it will be a future improvement, considering that collisions have a certain weight. And speaking of this, in the demo game, I test only a meteorite per frame, it's less precise but it increases performance.

Very good video and library

What is happening with collision detection of the bullets in the last example shown? It seems the bullet hits the sphere, but does not destroy it.

@agpxnet

5 ай бұрын

Good point. It's due to two factors (one of which I talk about at the end of my latest recent video on collision detection). The first is the speed of the projectile which, by moving at a certain pace (to be faster and being the collisions discrete rather than continuous), can cause "jumping over the obstacle". The second, that amplifies the issue of the previous one, is an optimization: instead of testing all 4 meteorites per frame, I only test one at a time and this can lead to non-detection of collisions. Unfortunately, due to the sprite multiplexing, the scrolling of the stars and a compiler that isn't too much efficient in code generation, sometimes we've to resort to these tricks to speed things up.

Really excellent explained - what kind of tools does one use to make such kind of visualisations?

@agpxnet

4 ай бұрын

I use a software made by me.

Very nice. Have you tried this with "big" (stretched 2x in both dimensions) sprites? I'm trying to use all 8 to cover most of the screen and when I get them moved into the next vertical position in time, they "tear" while being drawn.

@agpxnet

5 ай бұрын

Sorry, horizonal and vertical expansion (2x) are not supported. The "big sprite" is made of 4 x 8 sprites in normal size.

@andyc8257

5 ай бұрын

You're probably moving them before they have finished drawing. It's not enough to wait for drawing to start, you need to wait until it has completed before attempting to re-use the sprite.

@michaelgentner7708

5 ай бұрын

I did that in my program Tegra, i.e. with multiplexed stretched sprites I created a graphics screen that was overlaying the normal screen. Indeed the most tricky part was to get the timing right for the sprites not to flicker or lose lines. I even added a BASIC extension with commands for drawing lines, circles and such. That was 1987, maybe you can google it up, otherwise I can give you more information if you like.

Interessantissimo!

Unfortunately unlistenable due to the tts

@agpxnet

5 ай бұрын

I didn't think it was that bad, I'm sorry, but I assure you that with my English pronunciation it would be definitely worse. I also posted subtitles to make the video more understandable. I'll see if I can find another better voice.

@MrBrax

5 ай бұрын

@@agpxnet real voices are always better regardless of accent. At least with current tts voices, they sound way too robotic and distracting with no tonal inflections and meaning.

@agpxnet

5 ай бұрын

English is not my natural language. It's not a problem of accent, but of pronunciation. I need to improve my English, but unfortunately that takes a lot of time...

@MrBrax

5 ай бұрын

​@@agpxnetwell, good luck! It's an interesting subject, I enjoy old demos and tech flexes.

@LionelN

4 ай бұрын

As a foreigner, I think the tts is quite acceptable

Very interesting to learn about a dead technology. Very well explained but impossible to understand if you don't have a solid knowledge of 6510 assembly and VIC 2 registers. Thank you.

@3DPDK

5 ай бұрын

It's not at all a dead technology. Most of the 2D games played today use movable objects or sprites. Sprites are even used in some 3D applications. The speed of CPUs and higher amounts of memory in modern computers allows for a much higher number of sprites displayed on the screen at one time without the need for this type of multiplexing but the use of sprites in current graphics is very much alive and well.

@sandrodelacruz8125

5 ай бұрын

It's not dead, there's a huge community.

@kraftwerk974

5 ай бұрын

@@3DPDK I didn't know. I coded from 83 to 86 even though I never used multiplexing back then. Because I couldn't afford an assembler I first had to enter ML data in hex in Basic programs 🤣. Later things changed. I still enjoy all this stuff 😲.

@kraftwerk974

5 ай бұрын

@@sandrodelacruz8125 I meant that nowadays coders don't have a clue about how a CPU works. They call a function without knowing what a Stack is or does underneath etc.

@sfurta

4 ай бұрын

@@3DPDKraster beam is tied with pal or ntsc, hardcoded sync etc., this is really dead outside retro community.

Well, this information comes 40 years too late ... But thank you anyway ...

The interrupt at 2:16 should also preserve the P register via PHP/PLP

@agpxnet

5 ай бұрын

No, the P register is automatically pushed onto the stack when the interrupt is triggered, before the routine is executed. And it's restored by RTI instruction.

@vytah

5 ай бұрын

@@agpxnet oh yeah, you're right, I completely forgot.