mariuszw

Can you please reveal some more details on this?

I already know Z80 assembly from working on MAME project There are still two hires isometric games on C64: Bobby Bearing and Nosferatu. I was actually looking at Bobby Bearing and for now it looks that this one should be also quite easy to port to Atari.

That's quite likely to happen

Thanks, that did the trick. BTW: thanks for your awesome Altirra emulator. Makes Atari programming and code optimizing a joy

Here is next version of Fairlight port. New features: - screens are colored - keyboard is working (although there are issues under Altirra, it seems that not all keypresses are properly recognized, I am not sure if it is my bug - please test on real Atari and let me know, game keys are listed on title screen, please do not shift key, it doesn't work) - code optimization - game seems to be up to two times faster (or less slow) than C64 version, but still slows down when there is a lots happening on screen. Screen drawing which happens when hero enters the room is also faster. Mariusz. fl.obx

No chance for code to be slower than C64 - 1,79MHz vs. 1MHz makes the difference The code really looks to be converted line-by-line from Z80 to 6502, so I expect it may be quite well optimized later. I also wonder why original programmer didn't use hardware sprites on C64 - they would fit nicely in the game, making less work for the programmer (no need to convert software-sprite routines) and the game speed would be really good. BTW: is there an easy way to estimate real clock of Atari during executing given software, i.e. how much CPU time (expressed in MHx) is stolen by ANTIC? Here in Fairlight narrow screen is used (32 bytes), but in character mode. There are also 24 character lines displayed (192 pixel lines).

Here is my next C64 to Atari 8-bit port: Fairlight: A Prelude. For now only joystick is implemented, so you can walk around and fight the guards, but you cannot take and use items etc. It should work on real Atari, however I tested it under Altirra only. Enjoy! fl.obx

Thank you very much for your help!

This is nice idea and it would definitely save the cost fo scrolling, but it has some drawbacks: double buffering will be required to avoid tearing during display. This will definitiely requite many changes to the engine.

This is actually my code, already optimized The point is that lda $9f10,x has self modified address as an argument, and unrolling would create additional cost of modifing source adresses which would eat all benefit from unrolling. Can you elaborate a little bit about changing PMG via IRQ? What will be the savings? I'm already not using WSYNC too much (actually only two times a frame, to sync font base adress change) so how using IRQ would help here?

I guess any coder attempting to port any C64 game to Atari should know such VIC details And http://icu64.blogspot.com/ may help to reveal details about C64 game display layout without even attempting to disassemble a game.

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

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: First it moves tilemap, and then framebuffer. I attempted to optimize these in Atari version: Any ideas to improve these?

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.

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.

About optimizatoins: I with struggling with following routine: New Atari version is here: Any ideas if this can be improved, apart from creating lookup tables for shifting values three times left?

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

I like it, but I like previous picture more. This one has too much details, making them look not good, because of picture resolution being not big enough. Thanks for your efforts!

This has all the colouring apart from colors on items on status panel.

Picture is nice and I thinking about using it, however it looks that picture uses lots of CPU time due to mid-scanline color changes and I wonder if there will be enough CPU cycles to play a music, which I would also like to include in the game. Now I am waiting for th music to be done and then I will start implementing title screen.

Here is new version of Great Escape. It has PMG overlay implemented, so now it has some more colors. Thanks for Jose Pereira for coloring game screens. Also, it has bugfix for using fire button in joystick, so now it can be actually played, and items can be picked up, used, and dropped. ge.obx

Thanks for report. For instructions, please go here: http://c64games.de/phpseiten/spieledetail.php?filnummer=338and download Manual and Loesung (= Solution in English). Manual and solution are in English. These should give you some hints about where to walk actually

New version of The Great Escape attached. This version has fixed loading and it is supposed to work on real Atari. 64KB RAM required. If you run it on real Atari, please let me know the result. Also, graphical bugs are fixed. ge.xex

Thanks for the hints about performance. I discovered Altirra awesome profiler in the meantime and found all that wisdom . There is still some space left for the code, so I may try to unroll most expensive loops. The problem you mentioned turned out to be a bug in patching C64 routines, now fixed, thanks for report. Mariusz.

Yes, the screen is 32 bytes wide. And it needs 6KB RAM for display. I am not sure why flag is missing. It is not missing RAM, as C64 version still has some free RAM left. I think either it made game even slower so they didn't accept it, or just author missed the deadline for delivering the game, so he had to cut some features. "Score" in Spectrum version appears to be expressed in medals and not simple numerical value like C64 version does. BTW: I know you are doing lots of graphics for Atari, could you please make left and right ornament for playfield (vertical bars in yellow in C64 version) as PM/G graphics for Atari? This would allow me to have yellow for whole ornament like C64 has. Mariusz.