Is 3000+ sprites normal? :)

[Phantom]

No, no alpha blending this time. I got the frame rate up a bit (can't try it on the iPaq though, left the craddle at the office), I hope it's something like 60fps now.<br><br>MirekCZ: Of course you can have a look at the sources in a day or two, as usual.

[MirekCz]

Digby:beat me, but I would never allow myself to do that! - quality is most important<br>Phantom:hehehe, well I will be first one to download that.. btw have you got some alpha-blending demos too?:) (my alpha-blending routines are like 50% slower then transparent image drawing)

[Phantom]

MirekCz: Register dude. <br>Anyway, you'll probably be a bit disappointed when you see the sources. It's not as simple as the sprites unlimited demo this time.

[MirekCz]

I haven't seen sprite unlimited demo source actually, let me guess thru, you're going for run-lenght encoding? Would seem like a right step to take for a fast sprite engine and I can't see anything else that could make such a big gap in speed. I have did one with 80x86/MMX asm, it really rocks:) I haven't go for one with PPC cause I'm creating a very little game atm and it won't need that much speed I guess... it's very hard to develop anything anyway, cause I don't own an PPC:/ Ok, I'm away to register now...<br><br>PS.Maybe it's not the best place/time to do, but I remember your Phantom engine, Jacco.. from the good old software rasterization time.. it was really cool, you could actually create one for PPC, would roxx I guess:)

[MirekCz]

So how do you like me now?:) My first message, hah:)

[Digby]

Jacco,<br><br>Are you up to more trickery? <br><br>

[RICoder]

I won't allow myself to fall into a Monty Python rehash...<br><br>'witch, witch' ... 'burn her, burn her'

[Phantom]

Mirek, where you referring to the 'Phantom cyberspace' demo? I already did a voxel engine on the iPaq. The cuberspace thing was basically a double voxel engine, one voxel map coming from the floor and one from the ceiling, allowing for indoor scenes. Pretty cool on a 386, back then.

[MirekCz]

Jacco:hmm, might be, it's quite a long time;) I do remember that I wanted to be as smart as you back then... well actually I still do;) And yes, you did make the old machines "fly":)<br>Anyway you didn't answer my question, Is your new sprite demo using a run-lenght encoding to get such high numbers? With my functions I wouldn't been able to get more then like 25fps with that many 80x80sprites...<br><br>PS.run-lenght encoding, not sure if it's the correct name for it, but it's what I have heard once, basically it's about calculating how many transparent pixels are between non-transparent pixels and then just jump over them everytime you encounter them instead checking every pixel if it's transparent or not.<br>PS2.wrong again, the run-lenght is an approach where you check for pixels with the same color rather, I have just changed it to transparent/non-transparent cause that's what gives a big boost in sprite drawing...(is there a name for that?!? I used to name them FTIF with a friend long time ago.. and i still do (FTIF-fast transparent image format)

[Phantom]

Let's say it's one of the tricks I used. The most important 'trick' is an algorithm that allows me to draw this many sprites with zero overdraw. I believe you mentioned such an algorithm also a couple of messages back.

[MirekCz]

Ohh, you mean the span sorting algo mentioned by Paul Johnson? Yep, it should work great for big ball sprites... still not really usefull in real-life algorythms I believe (ie try to draw transparent trees with it and the number of spans that you will have to insert will be huge;) <br>Ok, I will shut up because noone likes me by now anyway;)<br>/me went to stole Phantom's backbuffer->frontbuffer copying routine couse his is damn slow (takes 1/60 of sec;)

[Phantom]

You have a better way of rotating a 240x320 buffer to the internal 320x240 iPaq buffer? FYI: I bypassed this in the bouncer demo. That demo draws to a 240x320 buffer on the Casio's, and to a 320x240 buffer on the iPaq. That's why the balls are tilted 90 degrees on the iPaq (you can only tell by looking at the texture).

[MirekCz]

well, as for now I was using a function which reads xpitch/ypitch values and saves to the buffer according to them - works very slow - I was trying to write a function which would work on 32bit values, it would be probably much faster, but I haven't got a possibility to test it anywhere and after crashing my friends IPAQ 2 times I gave up. (the idea is to read two long values from backbuffer, make some shifts/adds/ands and save two long values to IPAQ video buffer - from what I have noticed, working on 32bit values makes the memcpy routines 100% faster then working with 16bit values, so a big speed boost here might be possible (the and/add/shift function doesn't make big difference here from what I have noticed... no PPC to test anything thru:/

[Phantom]

I thought of that, but I didn't try it because I think the cache will perform poor this way: To plot two pixels at once you have to read from the source buffer two pixels on different scanlines. I should really try it to see if it's really faster or not. It's the core of EasyCE.

[MirekCz]

Yes, try it. I guess it will be MUCH faster... cache doesn't seem to do anything here - my function that rotates a bitmap while drawing works with pretty much the same speed and you read different scanlines with different order...<br>(it actually works few-several % slower but i would guess that's because the additional calculation it has to perform instead just increasing bitmap/screen pointer by 1 every pixel)