pouët.net

I have noticed this happening several times in some of the tiny 256byte intros and I just wanted to ask you why? Not for anything else rather than interest or something. I am just technically curious why would this happen..

Examples of intros where this happens:

- Tube by Baze. It was nice and smooth in a Pentium2. A friend of mine bought an AMD at 1700Mhz and I decided to try it to watch it at it's full glory! But it was slowing down like in my Pentium200mmx (Or perhaps a bit less..)

- Fireworks by Picard. Smoother in a Pentium1 than in a Pentium2

- [url=http://www.256b.com/download.php?id=141]Maze[/u] (Nice idea!) It draws fast the labyrinth in Pentium1, slower in some Pentium's 2.

- [url=http://www.256b.com/download.php?id=99]Grantday[/u] When I had first watched it in a Pentium2 I said "Hey! So slow??? :P" but I discovered these days in my old Pentium that it's good... same problems here again..

And perhaps more..

I was just curious from technical interest why this happens on these intros. Any ideas?

Optimus

P.S. It would be really funny thing for me to try to run one of this intros in VirtualPC on my friends Athlon 1700, and succeed in running them faster than in his real configuration! Haven't tried this...

It's probably a pipelining thing... you know, how code optimised for the Pentium will probably run faster on a Pentium I 66MHz than on a 486 100MHz, due to the Pentium having two execution pipelines and whatever.

Try reading Mike Abrash's "Zen of Assembly Language" sometime.. it's great for hardcore asm coding, heh...

Therefore, the virtual PC wouldn't improve it, as it would still be using the same CPU.

don't forget branch prediction and the great penalty associated with an incorrect prediction. I believe this was first introduced with the pentium pro, and then the pentium2. There were many cases where code would run faster on a pentium than on a pentium2.. and for several specific algorithms, it was really hard to get the same performance out of the pentium2.. but for typical use, the branch prediction was typically better.. and of course is even better now, in part because people and compilers tend to take it into account when optimizing (but obviously less so when optimizing for space).

I don't know what's going on with the AMD 1700MHz thing though :) As a total guess, maybe he's reading from the video memory? That's of course a big no-no nowadays..

bigcheese: do you really think that reading video memory on a recent PC would slow downs the perfomance that much ?

don't know for the other things,
but the AMD 1700mhz thing is weird, I've got an AMD 1400mhz ( with a GF3-64DDR )and TUBE is running really smooth and fast

Maybe some of the things done in 256byte intros are targetted mainly at the authors own pc? :-) (hint, may run slower on other cpu's).

I haven't tried reading from video memory in a long time. If something is reading from every pixel in 0a000h individually and doing operations in between, I doubt the gfx card developers give a crap how it performs anymore.. so I figure that sky's the limit :)

maybe you ran win xp/2k on the fast machines and win9x on the old ones or even dos..

the thing is that win2k/xp runs dos emulators and win9x runs it like it was dos (free to crash the machine/have fun ;-)

reading from video memory: on one card you might get 100 megs per second. on another, maybe less than one. so if the difference is greater than that it's probably about something else..

Wether a program reads from the VGA memory can be tested easily under Win9x/ME: Just try it both running in fullscreen as well as in windowed mode.
In fullscreen mode, the video memory is accessed directly. In windowed mode, the program actually writes to a buffer in system memory, thus speeding up the read transfers a lot.