I didnt think the C64 would have the horsepower to churn out the amount of bitmap work to do something like this unless you were talking about one picture every 4th refresh or something. But I'd love to see someone do a sample on this. After all the maths involved here can be optimized totally and probably unrolled a lot for speed.

Most of the "bitmap" plasma like effects I have seen uses large 8x8 or 4x4 blocks to get decent framerates on the C64.
_________________

Well I don't wanna diss the Commie, but I can't see this ever being done on a C64. Repetitive patterns is one thing, but this has different tiles everywhere. I've never seen anything that looks like it.
At least we can be sure the sound can be ported pretty well...

Why isn't there a C64 demo that looks like this game then if it's possible? plenty of tunnel effects yes, but all parts of each "circle" are the same colour. This has different colours in different parts of the ring.

why, is there an atari demo which has a tunel like this game?

Quote:

all parts of each "circle" are the same colour

have you ever seen a c64 demo with a tunnel, or read this thread at all? *sigh* let me help you:

http://noname.c64.org/csdb/release/?id=827

now dont go like fröhn, the code can be changed in no time to have it look exactly like yoomp, while keeping the speed. (in fact it would increase, since yoomp is much smaller.)

That demo won't run on my emulators, so I'll take your word for it until I get to put it on my C64. The screenshot is a symmetrical pattern though, not what's in Yoomp, and it's a lot chunkier looking. Though it'd be even harder to convince me there's any way around that!

Switching to 1541 II emulation for the drive works wonders in Vice for this demo. Normal 1541 emulation bombs.
_________________

Works 100% for me in VICE 1.22

I downloaded it , ran it in Vice only to realise on the end screen that I already seen and owned a real 5.25 version of this demo.

tomz
_________________

oswald: maybe it's even possible faster than on the atari? or have you looked at the code and checked if it cant be optimized? =)

whatever i agree with oswald, this should be very doable.... the damn thing doesnt even rotate, it boils down to almost trivial "colorcycling".
_________________

grop: I have done too many tunnels and similar routines to have a feel for speeds

DanSolo, anyhow YOU have to proove its not possible with the same cpu, and 90% similar gfxmode.

ok, I was too much on the attacking side. Anyways waiting for your proof that how it is not possible to do the same routine on a system with the same cpu and 90% the same screen mode? only the memory layout is different, oh and the doubled lines, well how about using only every 2nd line on the 64.., or Y stretched sprites, or alternatively writing the odd/even lines, the possibilities are countless..

As I said. I'd love to see this done. Maybe we should have a small coding competition here. - First to get it working and then thinking about optimizing the code. The texture lookup calculation seems like it could be precalculated, but I guess with the idea I have in mind I would run out of memory very quickly when I tried to unroll all texture lookups. (160x100 for whole screen, probably around half of that are actual tunnel pixels).
_________________

Hi guys,

I'm the author of Yoomp! - thanks for some nice words about it!

And yes - apologies for entering this atari-forbidden territory

I really would like to see Yoomp! ported to C64. It is simply an opportunity we shouldn't miss to make some cross-scene project, since so much of the code can be so easily ported.

Like many of you noticed, the biggest technical challenge is to port the actual tunnel routine. On Atari, it is 128x96 pixels area, but large parts of it are actually not rendered (where the side graphics is and in the middle of the tunnel). This allows it to run in 2 frames. I don't know how to render something in this resolution on C64, but if it's possible in 3, or maybe even 4 or 5 frames, that should be good enough. The reason this can still look good is that we render the ball every single frame, and since this is the most dynamic object, the user has a perception of smooth animation. Tunnel doesn't change that much, hence slow animation there might be fine. I guess once this problem can be reasonably well solved, the rest should be easy.

On Atari, one of the biggest problems was to fit everything in the memory. The tunnel-rendering code currently takes ca. 12KB ($0400-$3600). With proper texture and tunnel organization, the same code is used for rendering upper and lower halves of the screen. Another huge memory hog is the texture memory. The tunnel map is 8x4 tiles, each tile is 8x16 pixels, and for each texture pixel we need 8 bytes (for each 4 possible positions of a pixel in byte, and times two for scrolling the data). That would result in 8*4*8*16*8 = 32KB. Since that's too much, we make the tiles visually 8x16, but in the texture they are actually 4x16, as we use tile symmetry. That reduces the texture memory to 16KB ($8000-$c000) - still quite a lot.

For everything else you don't need to worry - the sources for Yoomp! will become available soon, and pretty much the entire game logic can be ported almost 1:1 to C64. Of course, the music, fx, title screens etc. would need to be changed, but that's peanuts

So, if someone is seriously considering doing it, I would be willing to help.
_________________