Elite must be ported to A8

[gauntman]

BTW, there are other line drawing routines that could be used. Two-step is supposed to be faster. I just question whether the limited number of registers on the 6502 will allow any speed increase since the faster ones draw from both ends of the line.

If you use the lookup table as suggested... maybe. It could be similar to unrolling the loop part way if you don't have to do much register swapping.

 

The double-step algorithm could be interesting, because it plots the next two pixels on the line, which may reduce shifting masks. Most versions of this I have seen plot the line from both sides and draw to the center of the line (see for instance: here). This might eat up too much of the ZP on the 6502 - but drawing from a single side may still be a win.

Edited March 24, 2010 by gauntman

[JamesD]

Elite draws with EOR. Probably because then they can use the same line routine for erasing too.

Which means it's not that optimized speed wise and it explains the breaks in the lines.

It's no demo. Ofcourse it's not optimized as good as possible. Most of the memory is occupied by the game itself.

A separate routine to erase the lines would be faster even without special cases, it would reduce flicker, and it should take less than 100 bytes.

Edited March 24, 2010 by JamesD

[emkay]

 

Unless the program does a complete re-render of the whole back-buffer every frame, surely there's going to extra processing involved. If you draw an XORed line to the back-buffer, then flip the displays, the back-buffer then contains a bitmap with no trace of the line you've just drawn (and which is now visible on the screen). You can't then erase the line you've just drawn by XORing it with the back-buffer, because the alternate buffers would always be one frame behind. Surely double buffering is most useful where the frame buffer is completely erased and redrawn each time. Ideal for a word-processor which does a complete refresh of the screen every frame, but not much good for incremental additions to the display RAM. At the very least, you'd have to swap the frame buffers, and then copy the visible buffer to the back buffer so that it always reflects the current state of the display. That would work, but at enormous cost in terms of the block move.

 

That's it. And this is done in the A8 version of RoF. Every frame is drawn fully new. In the C64 version you see that parts of the graphics get drawn after the "main" graphics were displayed. Not sure what they did exactly. But it surely was some "technique" to enhance the speed of the game.

 

Double Buffer is useless for such games, if you want to have the fastest speed. Perhaps people might mixup this technique with actual hardware, which has a co-processor that copies the backbuffer content to the screen immediately, without stopping the processing on the graphics content, while the CPU is calulating the vectors.

[Heaven/TQA]

Emkay....

 

no... everybody knows here what double buffer is... as they might coded double buffers???

 

need to have a look on the c64 version... but even if the version draws several times "over" old grafix... you still can use double buffer to avoid tearing.... double buffer has nothing to do with the drawing... only to minimise the flickering...

 

in some cases double buffer is slower. depends on when you are finishing the drawing...

[Wrathchild]

I'll confirm this later for sure but the draw routines in the BBC and C64 are pretty much the same code.

The Bresenham's algorithm is unrolled to a degree (as much as it needs to be in my mind considering this was 1984!).

The C64 version uses the raster line number count to avoid drawing lines across the raster, i.e. wait until the console area if necessary before drawing. This helps the tearing to a degree. BBC may do the same, I honestly haven't bothered checking yet.

 

As Miker pointed out on the other thread, a better line algo may help - however, certainly for the BBC version, I'm keeping most of the code 1:1 with the original version (i.e. routines and data are all still located at the same memory addresses). For the C64 port I have relocated most things and so have more flexibility here. I won't go back to the C64 port until the BBC one is complete though.

[Tickled_Pink]

Unless the program does a complete re-render of the whole back-buffer every frame, surely there's going to extra processing involved. If you draw an XORed line to the back-buffer, then flip the displays, the back-buffer then contains a bitmap with no trace of the line you've just drawn (and which is now visible on the screen). You can't then erase the line you've just drawn by XORing it with the back-buffer, because the alternate buffers would always be one frame behind. Surely double buffering is most useful where the frame buffer is completely erased and redrawn each time. Ideal for a word-processor which does a complete refresh of the screen every frame, but not much good for incremental additions to the display RAM. At the very least, you'd have to swap the frame buffers, and then copy the visible buffer to the back buffer so that it always reflects the current state of the display. That would work, but at enormous cost in terms of the block move.

 

That's it. And this is done in the A8 version of RoF. Every frame is drawn fully new. In the C64 version you see that parts of the graphics get drawn after the "main" graphics were displayed. Not sure what they did exactly. But it surely was some "technique" to enhance the speed of the game.

No doubt. I remember an old Jeff Minter interview in Computer and Video Games magazine where he reckons that they must have "cheated like hell" to get RoF working as well as it does on the C64.

[potatohead]

This could have been a delay draw, and or an ordered draw.

 

Drawing in a specific order can eliminate masking ops, and erase ops, depending on how things overlap, and the delay ends up pushing some detail into the raster, where artifacts like tearing don't matter so much. The players attention is already guided toward some action task, limiting the perception of artifacts on the screen. Think of it like an illusionists, or magicians slight of hand.

 

We actually do experience the entire event, but specific attention triggers can blank out visuals more or less completely.

 

In a game, this is draw order to minimize ops, planned to guide eye attraction, through need to view status indicators, or not such that the overall quality of display perception is considerably higher than what is actually occuring.

[Lazarus]

Perhaps people might mixup this technique with actual hardware, which has a co-processor that copies the backbuffer content to the screen immediately, without stopping the processing on the graphics content, while the CPU is calulating the vectors.

You just change the bitmap pointer, thats one LDA #xx STA $D018 per buffer flip on C64. Not a single bitmap byte needs to be copied.

[TMR]

That's it. And this is done in the A8 version of RoF. Every frame is drawn fully new. In the C64 version you see that parts of the graphics get drawn after the "main" graphics were displayed. Not sure what they did exactly. But it surely was some "technique" to enhance the speed of the game.

 

The attachment contains a deliberately mangled and then frozen copy of Rescue on Fractalus for the C64 (i apologise for the rough nature of the "work", i'm meant to be getting ready for a coach trip!) which i've just spent ten minutes crippling to stop the display buffer changes so it's possible to watch it render half the frames; you'll need to slow the emulator down to see it working properly but it demonstrates very plainly that the entire display area is being wiped out because you can see the memory fill, the landscape itself being drawn and the sky filled in last for every refresh.

 

Of course, i'm expecting some response about how it's been magically optimised to not remove the already drawn landscape but that's not true either; with this mashed version loaded and running in WinVICE, hit Alt and M for the monitor, then type...

 

f 6000 7f40 a5

 

...and when that's done, type x and hit return to quit the monitor and return to the game; that's a memory fill command which will overwrite the buffer i've locked the game down to displaying so everything (including the status bar) gets trashed, but you can see that the next refresh will rebuild the entire play area totally from scratch.

rof_trash.zip

Edited March 25, 2010 by TMR

[PeteD]

This exact same argument was started by emkay in another thread and I did what TMR has just done to prove that RoF draws the whole frame (well, I just changed the order in which the screens are displayed so you can see the back buffer) so methinks someone is having a bit of a troll when about 10 coders are telling him he's wrong. It's funny how he always manages to bring the C64 into it so any C64 coders who know he's wrong about double buffering in general get tagged as "freaks" again because "our" machine is involved

 

*edit*

Save yourselves some time, go back around here and read the whole flarn that's happening now. It's like time travel My post with the code to change buffers is 11324 if "someone" wants to see for themselves use it or TMR's

 

 

Pete

Edited March 25, 2010 by PeteD

[analmux]

...so methinks someone is having a bit of a troll when about 10 coders are telling him he's wrong...

 

Who is this 'someone' people keep arguing about? Keep it clear please. Or maybe it's a question of 'lack of balls'. Repeating sentences like 'someone is trolling' many times might end up with admins & mods believing this person is really a troll, but this would be without any justice. I didn't see trolling here, maybe some ignorance, but that was by a few people, not by a single one. So, show your balls and point out WHERE IS THE TROLLING you're complaining about?

 

About double buffering: OK, it's not needed that double buffering use more CPU-time than single buffering. That should be clear, and one can look it up at wikipedia or something. Flipping screenbuffers on C64 is as easy as on A8. However, on the other hand it also depends on what you're doing. Double buffering can always be interpreted as a solution when the computer isn't fast enough to do everything (of screen updates) within one frame. If the gfx handler only changes parts of the screen, then, in some situations, doing double buffering might need some more time than single buffering.

 

But, all this 'fighting' about what double buffering really is looks like avoiding the main question here: Would atari be fast enough to do it without double buffering? This would help to get more free memory for f.e. unrolled loops or whatever.

[PeteD]

It's trolling when EMKAY has already kicked off this whole argument in another thread and EMKAY was proven wrong but feels the need to be EMAKY and bring it up again in a thread that has nothing to do with RoF. EMKAY! happy now?

 

It's blatantly obvious who I'm talking about with "someone" in the context of the thread and my posts and my use of it is sarcastic. Just as it was blatantly obvious, at least to you, that Ste was talking about him when he said "mad as a fcking snake" despite never mentioning a name.

 

I'm sure the admins and mods are perfectly capable of reading a thread and deciding who is the troll.

 

 

 

Pete

Edited March 25, 2010 by PeteD

[analmux]

...still avoiding the main question...

 

and, you didn't answer mine. Which of emkay's SENTENCES here is trolling?

Edited March 25, 2010 by analmux

[analmux]

Double Buffer is useless for such games, if you want to have the fastest speed. Perhaps people might mixup this technique with actual hardware, which has a co-processor that copies the backbuffer content to the screen immediately, without stopping the processing on the graphics content, while the CPU is calulating the vectors.

 

It's a pity the CPU is always halted by Antic regardless of the instructions it is working on. Also when doing only computations it will get halted by Antic.

[PeteD]

Go read the thread and stop being a twat. I know you don't like me but if you can't work out that bringing up the C64 RoF AGAIN after all the crap last time (as linked to above) isn't trolling when we're in a thread about Elite then I can't help you. If you want to see my balls, come ask me to my face

 

 

Pete

[analmux]

Ehm, I did read the thread, and indeed emkay seems to ignore some stuff, but didn't make any personal comments, so isn't trolling in any sense.

 

...and stop being a twat...

 

This however. Let's see the board rules. This is clearly trolling, my dear.

[PeteD]

Trolling != personal comments, trolling means to post something, usually off topic, with the purpose of causing an argument. As he's already done this whole RoF thing once then I can only assume the purpose of bringing it up AGAIN is to either cause such argument or is due to some feeling of inadequacy for being wrong last time.

 

 

If you think saying I don't have balls is ok and me calling you a twat isn't there is a button next to my post, please click it.

 

 

Pete

[JamesD]

Please take your personal bickering to private messages.

This is a topic I don't want to see ruined.

[Heaven/TQA]

Mark, when where is the line drawing in your versions so I can have a look? you know your code best...

[emkay]

Ehm, I did read the thread, and indeed emkay seems to ignore some stuff, but didn't make any personal comments, so isn't trolling in any sense.

 

...and stop being a twat...

 

This however. Let's see the board rules. This is clearly trolling, my dear.

 

 

Im not acting on things that pass my argumentations or turn them around. Just to reduce trolling from the C64 camp.

I say you cannot do simple double buffering with calculated screens on an 8 bit like C64 and A8 and others, without losing CPU speed. That's why .... this time i name it "double buffing tricks" .... were done on the C64, while on the A8 real double buffering was done.

If you always draw the full screen into the buffer, ofcourse it will not get any slower than drawing directly to the screen memory. This is what I wrote aswell.

It's the problem with - re-using graphics - to save time, where double buffering is useless. Because you have to change graphics in two areas of the memory.

 

 

 

And btw.... back to the main thread.

 

When thinking about Elite, I guess the main tune has to sound more like this:

 

elitemod.xex

 

Still with the restrictions of RMT , using the workaround for the "missing waves" by KJMANN, I managed some modulated sounds, to make it a bit more genuine

[analmux]

When thinking about Elite, I guess the main tune has to sound more like this: elitemod.xex

 

Emkay, the filter voice & the rest is out-of-sync again. Maybe you can add a 2-frame delay to all the other instruments, to get everything back in sync again.

[Lazarus]

I say you cannot do simple double buffering with calculated screens on an 8 bit like C64 and A8 and others, without losing CPU speed.

+

Yes you can and it is damn easy.

 

If you always draw the full screen into the buffer, ofcourse it will not get any slower than drawing directly to the screen memory. This is what I wrote aswell.

The point of double buffering is to switch the visible screen memory and draw on the other. How often is it required to repeat that until you understand?

 

It's the problem with - re-using graphics - to save time, where double buffering is useless.

Which is not done. You are making it all up in your head but RoF does NOT reuse anything.

 

Because you have to change graphics in two areas of the memory.

No.

[emkay]

 

If you always draw the full screen into the buffer, ofcourse it will not get any slower than drawing directly to the screen memory. This is what I wrote aswell.

The point of double buffering is to switch the visible screen memory and draw on the other. How often is it required to repeat that until you understand?

 

 

How long does it take for you to understand that you wrote the same as I wrote just in other words?

[dwhyte]

*sigh*

 

Not again...

[emkay]

When thinking about Elite, I guess the main tune has to sound more like this: elitemod.xex

 

Emkay, the filter voice & the rest is out-of-sync again. Maybe you can add a 2-frame delay to all the other instruments, to get everything back in sync again.

 

 

Some update... incl some syncing

 

elitemodu.xex