Jump to content
IGNORED

New game - Great Escape


mariuszw

Recommended Posts

Well,

 

here are four pictures of the Steve Mc Queen cover of TGE - in JPG and GIF format. Maybe someone wants to convert them into Gr. 15 + PM or any other non-standard format (RAW, MAX, MCP, HIP, RIP, TIP, INT95, INP, XLP, whatever)...

tge_titlepix.zip

Edited by CharlieChaplin
Link to comment
Share on other sites

As this game is still a work in progress, what currently isn't implemented from the original game?

 

It seems that I have almost everything ready, apart from:

- title screen (propositions done, I just need to make decision which one to use)

- tiltle screen sound (this is being worked on, and propositions are ready)

- sound effects in game (also in progress)

 

Here is new version. It features colouring of items on status panel (thanks for Jose) and also some optimizations (thanks for Phaeron for his awesome Altirra debugger). Scrolling outside areas is now much faster, masking unvisible backgrounds is also optimized and there is small improvement to sprite rendering routine. Game is much faster when hero is walking outside buildings, but still slows down when there are many sprites visible. I am thinking to improve that by prerotating sprites and use prerotated versions while rendering, but this will require significant amount of additional memory, so it is going to be 130XE only feature.

ge.obx

  • Like 3
Link to comment
Share on other sites

About optimizatoins: I with struggling with following routine:

 

 

//----------------------------

--
L_JSR_($6EC1)_($6E26) OK
//------------------------------
$6EC1 A2 00 LDX #$00 ; 2
$6EC3 86 50 STX $50 ; 3
$6EC5 0A ASL A ; 2
$6EC6 26 50 ROL $50 ; 5
$6EC8 0A ASL A ; 2
$6EC9 26 50 ROL $50 ; 5
$6ECB 0A ASL A ; 2
$6ECC 26 50 ROL $50 ; 5
$6ECE 69 31 ADC #$31 ; 2
$6ED0 85 4F STA $4F ; 3
$6ED2 A9 3C LDA #$3C ; 2
$6ED4 65 50 ADC $50 ; 3
$6ED6 85 50 STA $50 ; 3
$6ED8 98 TYA ; 2
$6ED9 48 PHA ; 3
$6EDA A0 00 LDY #$00 ; 2
$6EDC A2 08 LDX #$08 ; 2
$6EDE 86 0A STX $0A ; 3
$6EE0 A2 00 LDX #$00 ; 2 (total 53 cycles)
//------------------------------
L_BRS_($6EE2)_($6EF4) OK
//------------------------------
$6EE2 B1 14 LDA ($14),Y ; 5+
$6EE4 21 4F AND ($4F,X) ; 6
$6EE6 91 14 STA ($14),Y ; 6
$6EE8 E6 4F INC $4F ; 5
$6EEA D0 02 BNE L_BRS_($6EEE)_($6EEA) OK ; 3
$6EEC E6 50 INC $50 ; 5
//------------------------------
L_BRS_($6EEE)_($6EEA) OK
//------------------------------
$6EEE C8 INY ; 2
$6EEF C8 INY ; 2
$6EF0 C8 INY ; 2
$6EF1 C8 INY ; 2
$6EF2 C6 0A DEC $0A ; 5
$6EF4 D0 EC BNE L_BRS_($6EE2)_($6EF4) OK ; 3 ; 41 * 8 = 328
$6EF6 68 PLA ; 4
$6EF7 A8 TAY ; 2
$6EF8 60 RTS ; 6 ; 12 cycles
; Total: 393 cycles

 

New Atari version is here:

 

 

asl ; 2
adc #0 ; 2
asl ; 2
adc #0 ; 2
asl ; 2
adc #0 ; 2
tax ; 2
and #$f8 ; 2
adc #$31 ; 2
sta sadr+1 ; 4
txa ; 2
and #$07 ; 2
adc #$3c ; 2
sta sadr+2 ; 4
ldx #$07 ; 2
sty sstorey+1 ; 4 (38 cycles)
sloop ldy mult4,x ; 4
lda ($14),y ; 5+
sadr and $ffff,x ; 4+
sta ($14),y ; 6
dex ; 2
bpl sloop ; 3 24 * 8 = 192 cycles
sstorey ldy #0 ; 2
rts ; 6 ; 8 cycles
; total: 38+8+192 = 238 cycles
mult4 :8 dta [#*4]

 

Any ideas if this can be improved, apart from creating lookup tables for shifting values three times left?

 

 

  • Like 1
Link to comment
Share on other sites

That's great, so the full gameplay is there which is great.

 

I don't have a video to show you, but when I was outside, one of the guards walked straight through a building and they were visible. I don't know if this is in the original game or it's an Atari specific bug, but I saw it.

 

I was wondering if you would consider producing several versions of the game with conditional assembly producing the different code? (Therefore it is no extra development work for you). You've already mentioned having a 130XE version, but I would like it to be able to see a 64K version which has those optimisations in but would drop the use of overlays for extra colour. Of course, if you don't want to see a fragmented set of versions, completely ignore me.

Link to comment
Share on other sites

That's great, so the full gameplay is there which is great.

 

I don't have a video to show you, but when I was outside, one of the guards walked straight through a building and they were visible. I don't know if this is in the original game or it's an Atari specific bug, but I saw it.

 

I was wondering if you would consider producing several versions of the game with conditional assembly producing the different code? (Therefore it is no extra development work for you). You've already mentioned having a 130XE version, but I would like it to be able to see a 64K version which has those optimisations in but would drop the use of overlays for extra colour. Of course, if you don't want to see a fragmented set of versions, completely ignore me.

 

I saw the bug with guards walking into the buildings, for now I think it is original (C64) bug, but it is yet to be proven.

 

About multiple versions: I am certainly not going to have multiple versions. Rather I prefer to have only one executable and turn features on or off on runtime. This 130XE version with optimized sprite (if I will really make it) will detect available memory on runtime and activate different code paths for sprites.

 

What is the point in having multiple versions? I understand that you don't like colour overlays and you want to turn these off? But then it will be simple black-and-white games, as the first preview I posted.

  • Like 1
Link to comment
Share on other sites

Can't help you with the game but just wanted to thank you for your hard work Marius...

 

I as I originally said loved the c64 version and at the time always thought that games like this were more than possible on the Atari, thank you for proving that right.

 

Sadly too many suits played the 'safe' game and left the Atari alone when it came to spending on dev of them...

Edited by Mclaneinc
Link to comment
Share on other sites

Hi. I don't know if Snicklin don't like the overlays or that he only want is that game can run on 64KBs Ram and it runs.

Is it?

 

 

P.s.- You can always disable PMGs overlays but the way is the gameplay there are certain colours you really need like the "MORALE" be in red and green and maybe some other(s) are important to play the game...

Link to comment
Share on other sites

It runs in 64KBs now and all PMGs overlays are done. What you see now is all PMGs in double scanline resolution to save Memory, if later there's free space and Marius want we can have PMGs single line resolution and better looking overlays on objects at the bottom or even add the flag, but this is up to him to decide :).

Edited by José Pereira
  • Like 1
Link to comment
Share on other sites

So,

 

here is "The Great Escape", latest version 3, compressed with Code3 Cruncher and some "borrowed" manuals and solutions from C64 webpages.

 

Don`t read the solution(s) if you want to solve this game yourself ! And errm, the manual(s) include the C64 keyboard controls (like e.g. Restore and Run/Stop), you have to find the appropriate A8 keys yourself...

 

 

GreatEsc_V3.zip

  • Like 1
Link to comment
Share on other sites

Any ideas if this can be improved, apart from creating lookup tables for shifting values three times left?

Two tables with 'adc #$31' and 'adc #$3c' included with shift ;)

 

If routine is not executed thousands of times per frame it's probably 'good enough' as it is. You did nice optimization on that lower part that executes 8 times, that should be enough.

 

ps. Nice trick with 'adc #0' and later 'and' to get lower and higher part of byte. Excellent work!

Link to comment
Share on other sites

Oh I like the PMG overlays, but if RAM is limited and I have to choose between PMG overlays and rolled out code, I'd take the rolled out code. [ Or other methods that increase speed but use extra RAM ]

Now I get the point. Actually PMG takes around 1KB of RAM (both data and code). Prerotating sprites which I mentioned would need around 3,5KB * 16 = 56KB (0-7 bits rotations and alos flipped versions), so there is no option to fit that data in standard 64KB RAM.

Link to comment
Share on other sites

Two tables with 'adc #$31' and 'adc #$3c' included with shift ;)

 

If routine is not executed thousands of times per frame it's probably 'good enough' as it is. You did nice optimization on that lower part that executes 8 times, that should be enough.

 

ps. Nice trick with 'adc #0' and later 'and' to get lower and higher part of byte. Excellent work!

 

Thanks. This particular routine is sometimes executed 500 times per frame, so it is worth optimizing. But I don't really want to spend another $200 bytes for lookup tables, and still the savings will be not too big (as you mentioned, optimizing the loop is most important).

 

Here is another example, routine which scrolls the screen. Screen in game consists of framebuffer of size 192 pixels * 136 pixels (at address $CF40 in C64 code, size $cc0) and background tilemap of size $198 bytes at $C008 in C64 code. When game needs to scroll in either direction, these two buffers are moved. Here is one procedure for scroll:

 

 

 

$8983 A2 00 LDX #$00 ; 2

//------------------------------

L_BRS_($8985)_($898C) OK

//------------------------------

$8985 BD 09 C0 LDA $C009,X ; 4+

$8988 9D 08 C0 STA $C008,X ; 5

$898B E8 INX ; 2

$898C D0 F7 BNE L_BRS_($8985)_($898C) OK ; 3 (14*256) = 3584

//------------------------------

L_BRS_($898E)_($8997) OK

//------------------------------

$898E BD 09 C1 LDA $C109,X ; 4+

$8991 9D 08 C1 STA $C108,X ; 5

$8994 E8 INX ; 2

$8995 E0 97 CPX #$97 ; 2

$8997 D0 F5 BNE L_BRS_($898E)_($8997) OK ; 3 (16*151) = 2416

$8999 A9 CF LDA #$CF ; 2

$899B 8D A7 89 STA $89A7 ; 4

$899E 8D AA 89 STA $89AA ; 4

$89A1 A2 0C LDX #$0C ; 2

$89A3 A0 00 LDY #$00 ; 2

//------------------------------

L_BRS_($89A5)_($89AC) OK

L_BRS_($89A5)_($89B5) OK

//------------------------------

$89A5 B9 41 CF LDA $CF41,Y ; 4+

$89A8 99 40 CF STA $CF40,Y ; 5

$89AB C8 INY ; 2

$89AC D0 F7 BNE L_BRS_($89A5)_($89AC) OK ; 3 (14*256) = 3584

$89AE EE A7 89 INC $89A7 ; 6

$89B1 EE AA 89 INC $89AA ; 6

$89B4 CA DEX ; 2

$89B5 D0 EE BNE L_BRS_($89A5)_($89B5) OK ; 3 (3584+17)*12 = 43,212

//------------------------------

L_BRS_($89B7)_($89C0) OK

//------------------------------

$89B7 B9 41 DB LDA $DB41,Y ; 4+

$89BA 99 40 DB STA $DB40,Y ; 5

$89BD C8 INY ; 2

$89BE C0 BF CPY #$BF ; 2

$89C0 D0 F5 BNE L_BRS_($89B7)_($89C0) OK ; 3 (16*191) = 3,056

$89C2 4C A5 87 JMP L_JMP_($87A5)_($89C2) OK

 

First it moves tilemap, and then framebuffer.

 

I attempted to optimize these in Atari version:

 

first loop:

lda $c009,x ; 4+
sta $c008,x ; 5
inx ; 2
lda $c009,x ; 4+
sta $c008,x ; 5
inx ; 2
lda $c009,x ; 4+
sta $c008,x ; 5
inx ; 2
lda $c009,x ; 4+
sta $c008,x ; 5
inx ; 2
bne loop ; 3 (11*4+3)*64 = 3008
(11*8+3)*32 = 2912
firs loop of framebuffer:
lda $cf41,y ; 4+
sta $cf40,y ; 5
iny ; 2
lda $cf41,y ; 4+
sta $cf40,y ; 5
iny ; 2
lda $cf41,y ; 4+
sta $cf40,y ; 5
iny ; 2
lda $cf41,y ; 4+
sta $cf40,y ; 5
iny ; 2
bne loop ; (11*4+3)*64 =3008
lda addr,x ; 4
sta code1 ; 4
sta code2 ; 4
sta code3 ; 4
sta code4 ; 4
sta code5 ; 4
sta code6 ; 4
sta code7 ; 4
sta code8 ; 4
dex ; 2
bne loop ; 3 ; (41+3008)*12 = 36,588

 

Any ideas to improve these?

Link to comment
Share on other sites

Any ideas to improve these?

As one of my friends put it 'nothing beats lda,sta ;)

 

Game looks fast already, I wouldn't spend too much time on extra optimizations. Only thing that comes to mind is to change something in main code. Throw out some extra step, use double buffering or something like that (all this based on not knowing anything on how it works :) ).

Link to comment
Share on other sites

As one of my friends put it 'nothing beats lda,sta ;)

 

Game looks fast already, I wouldn't spend too much time on extra optimizations. Only thing that comes to mind is to change something in main code. Throw out some extra step, use double buffering or something like that (all this based on not knowing anything on how it works :) ).

 

Yes, game is quite fast now. Most important is that it is faster than C64 version ;-). However, it is still slower than Spectrum version :( Also, I find it entertaining digging through the code and searching for better solutions.

 

This "change something in main code" will probably take lots of time, because game would need to be analyzed completely. (For now it is just C64 version with I/O patched for Atari and few small improvements here and there). I would rather spend that time looking at another game to port ;)

  • Like 1
Link to comment
Share on other sites

Humm... C64 not using hardware sprites that you said to me Skool Daze and Saboteur. I would like the challenge to get Memory to have the PMGs overlays colouring the screens:-).

 

P.s.- But I would also like that you put the flag on the left side, it's so empty there and the C64 coder didn't even bother to center the playing area.

Edited by José Pereira
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...