Why demo and not game?

[Wrathchild]

Could you imagine "Driller" or "Sentinel" on the A8?

 

More than imagining.... (though to be fair it does look the same )

 

There is still a lot to cover to see this to the end so don't get immediate hopes up too much.

 

The in-game movement and scrolling etc is next to master.

Then there is the use of player for the cursor to then be able to create/absorb objects.

Addition of the energy level indicator and scanner.

Sounds.

 

Regards,

Mark

[Heaven/TQA]

didn't I say that I have seen Sentinel few days ago

[Qwe]

What?
Are you porting the Sentinel for Atari or it's a joke? It's one of my favourite games!
Please post on Youtube the work in progress.

[Wrathchild]

No joke (1st Dec not 1st Apr )

[Qwe]

[emkay]

More than imagining.... (though to be fair it does look the same )

 

There is still a lot to cover to see this to the end so don't get immediate hopes up too much.

 

The in-game movement and scrolling etc is next to master.

Then there is the use of player for the cursor to then be able to create/absorb objects.

Addition of the energy level indicator and scanner.

Sounds.

 

Regards,

Mark

Let's hope to see a working game in a "not so far" day

And, particular all optimised with Antic D speedups.

 

Would be double great

[+Adam+]

Rescue on Fractalus is to slow for the A8, particular on PAL systems.

In "Rescue on Fractalus!" you can change the speed of flight using arrow keys (left/right). When you say "too slow" you are referring to which speed? Default?

Edited December 1, 2014 by +Adam+

[Heaven/TQA]

I think emkay points to the non-existing PAL adjustments... game core physics & controls are handled in the VBL and 50 FPS updated... while the NTSC version 60 times per second... so the game is more fluent in NTSC land...

 

as far as I remember I did not find PAL adjustments in the source code.... play the game as NTSC or PAL...

Edited December 1, 2014 by Heaven/TQA

[emkay]

Not sure. what techniques they used in the C64 version. If you compare both, you see graphical differences, and the C64 version draws parts of a frame , "between frames" . Do that in the Atari Version and get some (10-20%) fps more.

And, yes, there is also the PAL flaw , that makes the CPU sleeping for approx. 20% , while the game is slowed down, due to the VBI depending routines....

 

Probably, the game cannot produce more fps from ntsc to pal, but it could do MUCH more , in Detailed gfx, for example...

[Irgendwer]

- Deleted due to misinterpretation -

Edited December 2, 2014 by Irgendwer

[Heaven/TQA]

Not sure. what techniques they used in the C64 version. If you compare both, you see graphical differences, and the C64 version draws parts of a frame , "between frames" . Do that in the Atari Version and get some (10-20%) fps more.

And, yes, there is also the PAL flaw , that makes the CPU sleeping for approx. 20% , while the game is slowed down, due to the VBI depending routines....

 

Probably, the game cannot produce more fps from ntsc to pal, but it could do MUCH more , in Detailed gfx, for example...

 

I doubt that the CPU is 20% idle... what the VBL is handling, that got 20% less updates due to interrupt nature. and all drawings etc are not in the VBL. only double buffer switching... the fractal 3d code does not run in VBL. so basicly the buffer switching is done faster... but that does not mean in extense that the game itself runs 20% faster.

 

the c64 might be different. for more details of the c64 version check out the c# hacking issues. one of them handles RoF fractalus and Stunt Car Racer when they made a SuperREU patch (for the faster CPU).

 

PAL:

 

65816:

 

NTSC:

https://www.youtube.com/watch?v=5LxJUPpxm94

(5200 version has only 16k RAM!)

 

 

Lovely C64 (I guess PAL):

Edited December 2, 2014 by Heaven/TQA

[popmilo]

No joke (1st Dec not 1st Apr )

Hey! Awesome!

 

One of the best games ever deserves A8 version for sure!

 

ps. If I remember correctly from my own reverse engineering experiments on Sentinel - C64 version uses screen composed from multiple character sets. That is how it scrolls screen at those large steps. While player holds joystick in one direction code draws incoming graphics in background buffer and then just switches it on screen as it scrolls character screen. My question: as A8 has less chars per character set, shouldn't it be better to use maybe BBC micro version (that used pure bitmap screen) vs C64 version ?

[+JAC!]

Here there are very experienced programmers; in the scene why do they use their skills to make demos and not games?

It is easier to do demo?

 

1. For demo coders, coding good demos is more fun easier.

2. For game coders, coding games is more fun and easier.

3. For non-coders, both is typically impossible and it's also hard to understand 1. and 2. :-)

 

Creating demos is often about creativity in breaking limits while creating games it normally about game play creativity.

I tried several time in the past to create games and found out that I totally suck at it, so I stopped and keep on pushing machine limits for fun.

 

 

Edited December 2, 2014 by JAC!

[Wrathchild]

Thanks popmilo, co-incidentally I'd just been picking up on this as I'd deliberately been commenting the C64 $D0xx register settings and had turned focus back upon them. At the weekend I'd sorted the key-mappings and so could "U-turn" OK, but when using the direction keys a lot was happening code execution wise with nothing changed on the display other than some background redraw (presumably pre-prep for the area being drawn too). So thanks for the new direction it makes complete sense. Whether or not I can stick with what I have now will be fun to find out. The A8 is using multiple charsets to give 8 sets of 3 lines so a form of rotation is possible via the DLIs and maybe a bit of shifting in the charmap but that maybe at the sacrifice of not scrolling the same size segment. The alternatives are, as you suggest, to try the BBC code as the screen model the same 8 byte char format but not the font redirection or the other approach would be to try and replace everything with a bitmap screen (Antic-E) layout which should again be possible to use DLIs to 'shift' the screen existing rendered sections up and down. Phew, didn't think it would be easy Perhaps we can take the development discussion over to FormatWars?

 

To answer the OP though, I guess I prefer coding towards games - although most of these end up as technical-demos

Edited December 2, 2014 by Wrathchild

[popmilo]

... or the other approach would be to try and replace everything with a bitmap screen (Antic-E) layout which should again be possible to use DLIs to 'shift' the screen existing rendered sections up and down. Phew, didn't think it would be easy Perhaps we can take the development discussion over to FormatWars?

To be honest, my knowledge about bbc graphics modes and memory layout are close to zero... On the other hand I know every byte of C64s memory inside-out. I guess, even if it's virtual-character-scroll is harder to replicate on A8, it would be easier for me to understand ...

 

One of the best tools for figuring out what's going on in C64 game gotta be "ICU64". Remote debugger that can hook into running Vice or Frodo emulator and show graphics and memory state in realtime:

http://icu64.blogspot.gr/p/download.html

 

Try loading Sentinel in it, and turning on graphics in Character mode (memory range 4000-7fff).

Then try Text Screens in range from 7000-7fff and change character set between 4000-67ff (in $800 steps).

Looks like there are 5 charsets used in complex mix of vertical regions (max is 6 rows high = 240 chars).

 

Hey, if you're up to it, I'm always glad to start working on something new. PM, new topic, FW .. It's all the same to me, as long as discussion keeps going on

[emkay]

I doubt that the CPU is 20% idle... what the VBL is handling, that got 20% less updates due to interrupt nature. and all drawings etc are not in the VBL. only double buffer switching... the fractal 3d code does not run in VBL. so basicly the buffer switching is done faster... but that does not mean in extense that the game itself runs 20% faster.

So probably the CPU does not sleep in that time, but it does useless stuff?

 

NTSC:

... is PAL

 

 

It's also hard to compare the flow of a game in a Youtube video on TFT screens

 

 

 

 

Refering to the topic. A Demo coder could have done the game better.

[Wrathchild]

Try loading Sentinel in it, and turning on graphics in Character mode (memory range 4000-7fff).

Then try Text Screens in range from 7000-7fff and change character set between 4000-67ff (in $800 steps).

Looks like there are 5 charsets used in complex mix of vertical regions (max is 6 rows high = 240 chars).

 

Explains a lot My 'viewport' on the Atari is focused on the bitmap above $E000, which - up until now, has sufficed in viewing all the other screens.

[Heaven/TQA]

So probably the CPU does not sleep in that time, but it does useless stuff?

 

 

... is PAL

 

 

It's also hard to compare the flow of a game in a Youtube video on TFT screens

 

 

 

 

Refering to the topic. A Demo coder could have done the game better.

 

 

Rescue on Fractalus

-------------------

 

Next on my list was Rescue on Fractalus, an older (and quite cool)

Lucasfilm game that just didn't cut it in the 64 conversion, for a number

of reasons (that perhaps could have been avoided). There are at least two

versions of the game, one of which doesn't even work on a 128 (good 'ol $D030),

but I have the older version, which does work.

 

With a SuperCPU, though, there are a number of problems. The display

flickers terribly. The gameplay is smooth and not at all too fast -- in fact,

it is too slow. Specifically, the velocities and turning rates and such do

not give a convincing illusion of speed or excitement. The game is copy-

protected and uses a track-based fastloader, loaded from disk via B-E, which

also saves the high scores to disk. Clearly, this one is a bigger job: the

display is too fast, the game constants need adjusting, and the highscore code

needs to be replaced by some kernal calls.

 

The structure of this code is a little different. The main loop

handles the (double-buffered) display -- it does all the calculations and

draws to the two buffers. The multi-part interrupt loop does the rest --

it swaps buffers, changes the display in different parts of the screen,

reads the joystick, and performs the game updates which change your

position and direction. It also handles enemies such as saucers, but

doesn't handle the bunkers which fire at you from the mountains (the main

loop takes care of those).

What does all this mean? First, that the game can be a good ten

steps ahead of the screen, which makes things like targeting very

difficult. Second, that the bunkers almost never fire at you at 1MHz

(they go crazy at 20). Third, that things like velocity and turning

rate are rather low, because advancing or turning too quickly would

get the game way out of sync (unfortunately, they are still too fast

for 1MHz, making targeting difficult and movement clunky). On the

other hand, having the movement in the interrupt is the reason that

the game does not become unplayably fast at 20MHz, and means that

something besides a delay loop is needed.

The interrupt swaps buffers, but the main loop draws them,

and because it draws so quickly it can start clearing and drawing to

the visible buffer. To make sure this was what I was seeing, I reversed

the buffer swap code in the interrupt, so that the drawing buffer was

always on-screen. Sure enough, that's what the 20Mhz version looked

like.

It turned out to be pretty easy to force the main loop to wait

on the interrupt. Although I messed around (unsuccessfully) with

intercepting the interrupt loop, the buffer swap code actually

modifies a zero-page variable upon swapping. So all the main loop

has to do is wait on that variable before charging ahead. I may have

made it wait for two frames, because it made the game play a little

better.

 

Now, how to find the velocity and turn code? Well it takes

a keypress to change the velocity, so by hunting for LDA $DC01, and

tracing back, the routine can be found; at the very least the

affected variables may be found, and hunted for. For example, if

the result is stored in $D0, then you can search for LDA $D0. The

point is to locate the keypress processing code. From there, a little

trial and error (setting freeze points and pressing the velocity key)

locates the piece of code which deals with changing the velocity, and

in particular which variable corresponds to velocity. Finally, from

there it just takes another hunt for LDA velocity, ADC velocity, etc.

to figure out where the code for updating position and direction is.

In this case, I was pretty sure I had found it, as it went

something like

 

LDA velocity

LSR

LSR

ADC #$20

 

and this was added to the position. To check that this was the code,

I just changed the ADC, or removed an LSR, to see that the speed changed.

The code for turning left and right and moving up and down was similar,

and again after a little trial and error it was clear what code did

what. Again, it wasn't necessary to totally understand how these

routines worked exactly -- just the general idea of them, in this case

to see that a multiple of the velocity was used to change the position

and orientation of the player.

So, to fix it up, I just changed that multiple -- probably I

NOPed out an LSR above, to basically double the speed, and changed the

turning rates similarly. This took a little experimentation, as it

not only needed to be playably fast, but also couldn't overflow at

high speeds, etc.

 

But once that was working, all that remained was the highscore

table. Finding the table location was pretty easy -- I just got a high

score, and while entering my name froze the program, and figured out

what got stored where. From there it was pretty easy to figure out

what was saved to disk. From the original loader, I also knew where

the highscores needed to be loaded to initially (the highscore table

gets copied around a lot -- it doesn't just stay at that one location).

Figuring out the exact number of bytes to save took a little bit of

effort (saving either too many or too few bytes screws it up), but

from there it was clear what memory needed to be saved.

So all that remained was to add the usual SETLFS etc. kernal

calls, right? Wrong. The program uses all the usual kernal variables

(from $90-$C0) for its own purposes. Also recall that I wanted the

program to work with device 9, etc. To get around this, I did two

things. First, when the program first starts, I save some of the

relevant variables to an unused part of memory -- in particular, I

save the current drive number. Second, before saving the highscore

file, I actually copy all zero page variables from $90-$C2 or so

to a temporary location, and then copy them back after saving.

That way there are no worries about altering important locations.

Finding memory for the load/save patch was easy -- I just used

the area which was previously used for the fastload load/save code.

There was enough for the necessary code as well as temporary space

for saving the zero page variables.

 

Finally, I changed some text from Rescue on Fractalus to

Behind Jaggi Lines, to distinguish it from the original, and that

was that. Works great! And is now more playable and challenging;

in short, more the game it always should have been.

[emkay]

Interesting to read.

It explains, why the C64 version runs "faster" as it should, if the code from the A8 was running, and states, what I wrote in other threads before.

Flipping "unfinished" frames is what you see on the 1st sight in the C64 version, while on the A8 all frames get fully drawn, before the pageflipping.

The weird result, using the "unfinished frames" , do it in a controlled way, to suggest more things happen on the screen than actually happens.

The A8 version is, as weird as it sounds, a cut down from real highspeed Computers of that "old" days. Those "special" optimisation have not been done as in the C64 version.

 

So, what to think about that?

Is it cheating, as it has been done with the C64 version?

Is it lame, not to have those "optimisations" in the Atari version?

[Rybags]

I doubt the C64 version displays an unfinished buffer, or does a page switch during active display (that would show real bad tearing).

 

By the description though, the C64 (and possibly Atari) version expects a redraw to always take at least 1 frame which explains the unwanted behaviour on turbo CPU before he fixed it.

[MaPa]

Here there are very experienced programmers; in the scene why do they use their skills to make demos and not games?

It is easier to do demo?

I think that to do a demo is more difficult that doing a game at least from my point of view. I did some games already but no demo yet (only 1k intros and big intros with just only one effect) and I think I'll never do a demo. IMHO regular programmer is able to code some simple or even advanced game with basic approach like copying some bytes from here there. Add some DLI' to color it up and you can have good looking game. Btw. moreover you can write games even in higher level languages like Quick, Action!, TurboBASIC etc. and I can't imagine using it for a demo.

 

Today demos on the other end IMHO needs more knowledge about the system about math etc. for plazmas, twisters, 3D stuff... And maybe therefore programmers tend to show their skills in a demo.

 

But the hardest part in both areas is to get some idea what to do. What the game should be about, how will it play or how make old effect better or think out something new.

 

And at last.. look at Kaz kompo.. there are tens of games every year participating but how much demos are done?

Edited December 4, 2014 by MaPa

[Heaven/TQA]

I just finished one large project entering Silly Convention demo compo... and MaPa is particular right... a game could have been done faster (if it is simpler)

 

Emkay... well... gimme some days rest and I return to RoF and we will see how the A8 is working in detail as I am continue my fractal researches

[Rybags]

I just played them back to back in emulation (Pal) - it's night and day with C64 vs A8, C64 is a slideshow regardless of complex stuff going on or not, A8 version is much smoother and you feel much less wanting for faster updates.

[Heaven/TQA]

you can not speed up the fractal/2d projection, rotating etc as this is CPU power needed... then the special EOR filler (well partially unrolled for each scanline) might be double on c64 due to no mode7 (96 scanlines processing vs 48).... the CPU saving for moving sprites around on c64 will not catch up the spend cycles for the 3d calculations....

[Rybags]

That's the big penalty - having to do 2 stores, and probably throw in an INY as well. And the slower CPU. And the bitmap arrangement might penalise it more as well.

PMG movement on Atari - I don't think there is much... the UFO, the player's shot, the windscreen pillars (which remain static).