Jump to content

Photo

Sideways updated


5 replies to this topic

#1 ParanoidLittleMan OFFLINE  

ParanoidLittleMan

    Stargunner

  • 1,054 posts

Posted Wed Jan 3, 2018 9:33 AM

http://atari.8bitchi...H/sideways.html

 

There is YT video and DL on page. Unfinished game from about 1991. But pretty well coded - 50 fps constant screen refresh.
Based on Jamie Woodhouse development version. Added changes to make it playable as usual games - limited life count, losing life when energy is out.
When restarting game (after losing lives, or pressing Esc. for abort), score is reset, but add-ons remain, and continues on last level played.
So, those will not reset - partially because level difficulty does not increase by progress in game.

 



#2 TheNameOfTheGame OFFLINE  

TheNameOfTheGame

    Dragonstomper

  • 631 posts
  • Location:Almost Heaven, West Virginia

Posted Wed Jan 3, 2018 10:34 AM

Nice! Working good on real hardware.  Nice, fun Uridium type game.



#3 fedepede04 OFFLINE  

fedepede04

    Chopper Commander

  • 121 posts

Posted Wed Jan 3, 2018 10:56 AM

http://atari.8bitchi...H/sideways.html

 

There is YT video and DL on page. Unfinished game from about 1991. But pretty well coded - 50 fps constant screen refresh.
Based on Jamie Woodhouse development version. Added changes to make it playable as usual games - limited life count, losing life when energy is out.
When restarting game (after losing lives, or pressing Esc. for abort), score is reset, but add-ons remain, and continues on last level played.
So, those will not reset - partially because level difficulty does not increase by progress in game.

 

looking good, how many fps was it before?



#4 ParanoidLittleMan OFFLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,054 posts

Posted Thu Jan 4, 2018 1:35 AM

It was 50 fps - as said: "pretty well coded - 50 fps constant screen refresh." .

It is game 'prototype' - so basically demo of how it plays, looks, with some 8 levels/maps. No life count limit, when energy lost it just continued to next level.

So, all I did is: adding couple screens like title pic with short instructions, game over screen. Player life count control, when energy lost losing life ... And high score displaying, updating. This latest  was actually hardest because strange way how code for score displaying works - but it was coded for speed, not for easy understanding :)



#5 fedepede04 OFFLINE  

fedepede04

    Chopper Commander

  • 121 posts

Posted Thu Jan 4, 2018 9:37 AM

Hi

thx yes i can see that now, i must a misread that first time, i read it as, that it was after you work on it, that it run 50fps  :lol: 

yes it can be very hard to add things to an others program, you don't know what the idea mind set was when they coded it, i have had the same joy doing enduro racer, there are places in the data, where i can't make new variables it will stop the program from running.

 

but you know all about this, all your work is great and to good use for many.

hope you keep doing it.  :)

 

one thing that could be great was if a person like you did a tutorial on how to dissemble a game/program, that show us mortal how to see if code is program or data and where to start  ;)



#6 ParanoidLittleMan OFFLINE  

ParanoidLittleMan

    Stargunner

  • Topic Starter
  • 1,054 posts

Posted Thu Jan 4, 2018 11:56 AM

Oh dear God, now I'm some immortal, or some geek God :lol:

Considering disassembling: I disassembled about 10 games and TOS 1.04 (without AES, Desktop part) . Sideways was on of the firsts. I was on idea to make it working on any RAM area, so to make it regular TOS relocatable program - it is done for begin address $144C0, with screen buffers at $70000 and $78000 . But I was not able to do it properly, so it worked not flawless on higher addresses. I abandoned idea, and used other ways to make it work from hard disk, on Falcon. Maybe I could do it now better, with some more experience, but really no need to waste time, I think.

So, this update of Sideways is done with 100% original object code, no reassembling. I just inserted jumps on locations where was need to change code. Placed 2 added screens (packed) and about 800 bytes of extra code below $144C0 - and it still works fine even with TOS 2.06 when is placed in AUTO folder of floppy.  For instance, when energy runs out, it jumps  to same code as when ship explodes after losing shield. Only that then needs restoring full energy. Most time went on tracing game, and finding locations where variables for shields, energy, life count, score are placed. New variables are of course outside original code.

 

Disassembling: it is very hard to find all locations which are not code, but some variables, constants, data in middle of some longer program, or binary area. And is much easier with regular TOS relocatable exec. Because then, you can check it for correctness almost 100% bullet proof:  just need to reassemble your S file, and if it is 100% same as original, you found all locations what are relocatable. In some cases it may take couple days, In some it can be done in less than hour. I used Devpac 3 for all it. Tried with Easy Rider and some other tools, but they was not smarter (or I was not smart enough to use them properly ?) .

For instance, OIDS was easy case - because it was compiled in special way, so all data was in data segment. Probably same is case with Dungeon Master - but I did not disasm. it. Swiftar is another one, done likely with same compiler, and was about 1 hour to disasm. Recognizable by jump table at start.

What was hard was Prince of Persia - mixed code and data overall, then some seemingly constants, which are actually displacement between 2 locations in exec, so you need to find exact locs for what it stays, and put there labels, and replace constant with label2-label1. That is pretty hard to discover.

What I did not yet, is disassembling some low RAM binary. It is not possible to do it with Devpac directly. Maybe with some tricks. In theory, you can do it with Steem, but it just produces not useful S file, should after it correct zillion lines manually.

Disassembly is not needed for some smaller changes in games, for sure. Then you just add patches, what means jumps to extra code, and jump back. But in cases like Uridium, Hard 'n' Heavy ... it was better way. Time spent on disassembling paid, and then was much easier to add new code parts, to change some existing ones, and like. 

And you can even fix bad RAM management of games - for instance Uridium did it pretty poorly - there was large free area in middle of main exec, instead using bss area for that. So, I cut down exec size from some 350 KB to 160 KB ! Without packing. Certainly, there is plenty of Atari SW what could be made much better, but life is short, so most of it will remain as is.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users