Yoomp

[emkay]

Guess, the finished game then will look more colourful than the Atari version. The Player will also take note about some weird charmode

movement, making the game moving at a lower resolution....

 

Very interesting: some "known guy" makes a simple charset rotation, to compare it with the full graphics routine on the A8 game, and people congratulate him for the "solution" looking like Yoomp.

 

[Heaven/TQA]

Eru... i have done years ago a zooming Taquart logo on Lynx...its damned easy machine imho... search for bastian schicks pages i guess...

[Heaven/TQA]

http://www.geocities.com/SiliconValley/Byte/4242/lynx/

[eru]

http://www.geocities.com/SiliconValley/Byte/4242/lynx/

thanks!

but it will take time probably before I try to do anything there.

[eru]

Very interesting: some "known guy" makes a simple charset rotation, to compare it with the full graphics routine on the A8 game, and people congratulate him for the "solution" looking like Yoomp.

I'm not sure what you're talking about here - from what I know, Frohn's routine is real rendering, like on Atari, just a bit slower.

And he's using some interesting char-mode tricks to reduce the code size.

[Albert]

Guess, the finished game then will look more colourful than the Atari version. The Player will also take note about some weird charmode

movement, making the game moving at a lower resolution....

 

Very interesting: some "known guy" makes a simple charset rotation, to compare it with the full graphics routine on the A8 game, and people congratulate him for the "solution" looking like Yoomp.

 

Yeah, I think some people underestimate how much work is required to turn a graphics demo into a fully playable game.

 

..Al

[emkay]

Very interesting: some "known guy" makes a simple charset rotation, to compare it with the full graphics routine on the A8 game, and people congratulate him for the "solution" looking like Yoomp.

I'm not sure what you're talking about here - from what I know, Frohn's routine is real rendering, like on Atari, just a bit slower.

And he's using some interesting char-mode tricks to reduce the code size.

 

 

Perhaps it is "rendering" . But it is simply rotating the content. No zooming tiles are there and simply the whole game is missing.

[eru]

Perhaps it is "rendering" . But it is simply rotating the content. No zooming tiles are there and simply the whole game is missing.

It's not an issue at this stage of development, really. First it needs to be verified if a tunnel like this is possible at all, then we (they) can worry about porting the actual game.

[+remowilliams]

Interesting thread. Didn't try running the demos they've put together, as I don't have a C64 emulator on my system.

Here's a quick comparison of the .prg I found there.

 

[potatohead]

Perception of motion is different from perception of flicker.

 

Average perception of flicker, using central eye vision is about 50Hz. This varies from 40 to 70 or so. Edge of eye detection of flicker varies more widely, and has a higher average, somewhere about 70Hz or so.

 

Motion under 8fps is seen as a series of stills. From 8 to ~25 or so frames per second is seen as motion, and the differences between frame rates is easy to discern for most viewers. This number combined with the flicker number above is exactly why most quality theater projectors flash two shots per frame to reach 48Hz instead of the 24, I think is the norm for film.

 

Motion above 30hz and up is seen as smooth. Where that break happens varies by person, but all of us rapidly lose the ability to differentiate frames per second above 30hz. The big confusion here is flicker -vs- actual motion! High contrast objects exhibit both flicker and motion. The motion component is generally seen as smooth, with little overall differentiation being possible between frame rates, but for some very specific cases. The contrast between it and other objects then causes flicker, between frames, that can be seen and differentiated.

 

On computer monitors, and in games in particular, these things combined to break the illusion of smooth motion at rates higher than 30Hz.

 

Our own eyes have a variable refresh, with the entire field of vision taking considerable time. That's the differentiation between central and outer vision. We trade detail and color bandwidth for raw frame rates. Being hunter-gatherers, we need motion detection at our edges of our visual field. We then locate this and focus on detail where appropriate. The actual perception of a visual field is a combination of raw data from the eyes, complex transforms and "fill - ins" that blend together to produce a moving scene.

 

A really great analogy is sound. Below about 20hz, again depending on the person and the medium, cycles of sound translate into changes in overall volume instead of raw tones. The motion works the same way, with a fairly sharp break between stills and just smooth motion. When people claim to hear below 20Hz tones, it is highly likely they are hearing artifacts caused by either the generation of the tones (distortion), or by the tones themselves (resonance).

 

IMHO, people claiming to differentiate higher frame rates are actually making a valid claim on the quality of motion. On computer displays, and with game graphics in general, separating the two (motion and flicker) generally makes no sense. From the game engine stand-point, optimizations aimed at frame rate sacrifices, make total sense as they will have a lot less impact than most people think they will.

 

One artifact of our visual system, in play in this excellent game, is the brains ability to "fill in" details for us. The moving ball actually triggers a greater sense of motion smooth-ness in the tunnel than would be perceived otherwise! This filling in of details happens quite often. One very common case, that's fun to toy with, is partial occlusion of one eye. When done intermittently, the brain simply maintains existing depth cue information, leaving the perception of depth and overall image quality undisturbed. This is why one can have dust, or particles resting on both eyes, yet see little overall problems with it. Close one eye, and that information is lost. The most frequent response is to then clean that eye to obtain the sharpest image possible.

 

(I know, for the bar, but maybe relevant to the C64 - Atari comparisions and or tradeoffs we are about to see in the near future.)

[Albert]

Interesting thread. Didn't try running the demos they've put together, as I don't have a C64 emulator on my system.

Here's a quick comparison of the .prg I found there.

 

Thanks for putting that image together. It's really hard to gauge how that will look until they put real textures in there. I also wonder how good the colors will look. With the C64's 16-color palette I'm not confident that it'll approach the polish of the 8-bit version.

 

..Al

[Heaven/TQA]

wait until they found a c64 optimised way to do the tunnel... if so... they are implementing the rest... Fröhn is just doing some technical tests... don't overrate this kind of protos...

[emkay]

Perhaps it is "rendering" . But it is simply rotating the content. No zooming tiles are there and simply the whole game is missing.

It's not an issue at this stage of development, really. First it needs to be verified if a tunnel like this is possible at all, then we (they) can worry about porting the actual game.

 

Well, "all" the A8 can do, the C64 can do also... even if slower. So the question "whether it is possible or not" wasn't there.

Rescue on Fractalus and Koronis rift are also available on the C64... even if "half" of the original.

Many games on the C64 have a lower game resolution. While you see 320x200 or 160x200, many games, particular when "3D looking" are at the resolution of 40x25 (mostly the top seller games like outrun)

For comparision. Yoomp has the resolution at 160x100 , and it plays at the same resolution.

Or Gauntlet. The game plays on the C64 in 4x4 pixel, on the Amstrad at 2x2 pixel resolution.

 

There is still one fact that disturbs "the logics".

 

C64 can do all the A8 can do, even if it is slower.

Atari can not do like C64, because it does it slower then.

 

You see this logics everywhere you go into 8 bit computer scene related...

[Bryan]

Any interest in porting it to th Jaguar!?!? id love to have it on the Jaguar buddy!

 

 

And we need a port to the Lynx as well. I want to play it anywhere! (Lynx has a version of a 6502 at 4 MHz)

 

Again, kudos to eru for that great game!

 

 

Regards,

Beetle

 

The Jaguar will have to wait for Yoomp 2000!

[majinbuu]

The author of this game needs to be shot. It's taken over my life the past few days.

 

Does he have any idea how much time i've spent on this game, it bloody great.

 

What are some of your high scores? Also, is there a finite number of levels?

Edited December 18, 2007 by majinbuu

[emkay]

Some more thoughts:

 

Doing a rubbish calculation, the C64 needs 19200 CPU cycles per frame for imitating the double scanline mode of the A8.

The A8 has no DMA cycle stealing every 2nd scanline, leaving almost the double of cpu speed there.

 

Well. What to think about the Lemon64 thread? Even if I don't like that Oswald guy, he and Fröhn seem to be cabable to do high level stuff on the C64.

And, as Heaven wrote: ERU, Oswald & Fröhn, what a team ....

 

What's the conclusion?

On the Atari we have actually 1 coder who impresses with stuff you never would expect, like Numen or Yoomp.

While on the C64 you can find 100s of high level coders like Oswald or Fröhn ...

[Rybags]

Well, in all likelyhood, won't our NTSC version be 1 movement per 3 frames?

 

A C64 version might well have the same compromise. Problem is, that will be for PAL which translates to 16.67 FPS.

 

NTSC - who knows, maybe one in 4 frames.

 

But, there's always the '64 mode on a 128 - doing the CPU overclock trick effectively brings that machine much closer to Atari speed.

 

I haven't had a look at the game code - no idea if some trick could be done in character mode + FLI to give lores at a high frame rate.

 

But, remember: any trick that might be used to give high frame rate on a '64 version would probably work for the Atari too.

 

That is, unless the entire background is just done using sprites, but that introduces it's own set of headaches.

[Heaven/TQA]

What impressed me more is the lack of c64 information Eru has or had... he seems really an atari geek...

[Rybags]

Transferring skill-base from one to the other is pretty easy. Just that you have to learn some things, and unlearn others, and employ differing techniques at times.

 

I think with the dev-tools and disassemblers we have these days, porting games should be much easier.

[eru]

Doing a rubbish calculation, the C64 needs 19200 CPU cycles per frame for imitating the double scanline mode of the A8.

The A8 has no DMA cycle stealing every 2nd scanline, leaving almost the double of cpu speed there.

Not really correct, in the thread on lemon I clearly said: "there are 886 bytes modified, which is 4430 extra cycles"

And from what I know, DMA on c64 doesn't really steal cycles.

 

Well. What to think about the Lemon64 thread? Even if I don't like that Oswald guy, he and Fröhn seem to be cabable to do high level stuff on the C64.

And, as Heaven wrote: ERU, Oswald & Fröhn, what a team ....

Unfortunately, we don't make a team. Fröhn works by himself from what I know. And I don't really help, perhaps later. But the guys know what they're talking about

 

What's the conclusion?

On the Atari we have actually 1 coder who impresses with stuff you never would expect, like Numen or Yoomp.

While on the C64 you can find 100s of high level coders like Oswald or Fröhn ...

Bullshit, sorry. We have quite a few skilled coders, 0xF (aka Fox, the main guy behind Numen), pr0be, XXL, TeBe, just to name a few. I agree C64 scene has probably more, but it's normal, as the scene is much bigger.

 

Well, in all likelyhood, won't our NTSC version be 1 movement per 3 frames?

Yes, it's 3 frames, 20fps

 

A C64 version might well have the same compromise. Problem is, that will be for PAL which translates to 16.67 FPS.

It doesn't look bad at all in 16.67 fps, if they squeeze it in 3 frames, it should be fine. I still have some doubts about it though. Perhaps it will need to be made smaller.

 

But, there's always the '64 mode on a 128 - doing the CPU overclock trick effectively brings that machine much closer to Atari speed.

Here comes the C64 scene approach I truly love - everything should work on a base C64.

 

I haven't had a look at the game code - no idea if some trick could be done in character mode + FLI to give lores at a high frame rate.

But, remember: any trick that might be used to give high frame rate on a '64 version would probably work for the Atari too.

You can't really optimize what is there now,unless you pay some visual tradeoff...

 

That is, unless the entire background is just done using sprites, but that introduces it's own set of headaches.

This has been considered, and for now seems a bad idea.

 

What impressed me more is the lack of c64 information Eru has or had... he seems really an atari geek...

???

 

Transferring skill-base from one to the other is pretty easy. Just that you have to learn some things, and unlearn others, and employ differing techniques at times.

I think with the dev-tools and disassemblers we have these days, porting games should be much easier.

For this one, you don't even need a debugger, the sources will be released at some moment. And if somebody seriously considering a port asks me for them now, I will be happy to share even today.

 

 

PS. For people interested in a Lynx port, see here: http://www.atariage.com/forums/index.php?showtopic=118352

Edited December 19, 2007 by eru

[Rybags]

The C-64 DMA is interleaved when possible, since the RAM is 2 MHz effective and the CPU is only 1, that means all refresh cycles are transparent and most screen DMA is likewise.

 

But, you lose 1000 cycles for the character map - regardless of graphics mode.

 

I don't have the specifics in front of me, but I believe you also lose 1 cycle per sprite data pointer access, and 1 cycle per sprite for each (new data) line displayed.

[emkay]

Doing a rubbish calculation, the C64 needs 19200 CPU cycles per frame for imitating the double scanline mode of the A8.

The A8 has no DMA cycle stealing every 2nd scanline, leaving almost the double of cpu speed there.

Not really correct, in the thread on lemon I clearly said: "there are 886 bytes modified, which is 4430 extra cycles"

And from what I know, DMA on c64 doesn't really steal cycles.

 

 

If you say.

But what command reads the content of a 16-Bit adress and copies the value into another 16-Bit adress within 5 CPU cycles?

 

Well. What to think about the Lemon64 thread? Even if I don't like that Oswald guy, he and Fröhn seem to be cabable to do high level stuff on the C64.

And, as Heaven wrote: ERU, Oswald & Fröhn, what a team ....

Unfortunately, we don't make a team. Fröhn works by himself from what I know. And I don't really help, perhaps later. But the guys know what they're talking about

 

What's the conclusion?

On the Atari we have actually 1 coder who impresses with stuff you never would expect, like Numen or Yoomp.

While on the C64 you can find 100s of high level coders like Oswald or Fröhn ...

Bullshit, sorry. We have quite a few skilled coders, 0xF (aka Fox, the main guy behind Numen), pr0be, XXL, TeBe, just to name a few. I agree C64 scene has probably more, but it's normal, as the scene is much bigger.

 

Take it as a quota.

When asking about a coder, one on the A8 may say "here I am", while 100 on the C64 do the same at the same time.

[eru]

Not really correct, in the thread on lemon I clearly said: "there are 886 bytes modified, which is 4430 extra cycles"

If you say.

But what command reads the content of a 16-Bit adress and copies the value into another 16-Bit adress within 5 CPU cycles?

The rendering routine, that does STA on Atari, on C64 would need to do two STAs, hence only 5 cycles extra per byte.

[Heaven/TQA]

Eru... I thought that you are one of the best 6502 coder I know (together with Fox) and i thought you have touched C64 in last 10 years...

[eru]

Eru... I thought that you are one of the best 6502 coder I know (together with Fox) and i thought you have touched C64 in last 10 years...

No I haven't. Why would I?

I also haven't touched Apple II, Atari Lynx, Atari 2600 nor NES - they all use 6502, right?