Spire of the Ancients (WIP)

[+Cafeman]

This game looks great, what a good effort. Thanks also to Trebor for putting up the demo video so we can see what it's like.

[+SmittyB]

I've now removed a lot of slowdown caused by the look function so at least in emulation and on PAL hardware (which just isn't as susceptible to slowdown because of the larger delay between frames) things are mostly running smooth, at least to the point where if there's slowdown it's because you can see some large objects on screen.

 

I've added a 'Paused' message on screen when the game is paused (naturally) because even though the colours already turn grey when paused it's not obvious if you're in a darkened area or are playing on a tiny portable B&W CRT like the bohemians you are.

 

Additionally the keypad keeps breaking in weird and wonderful ways, seemingly without me needing to do anything. I had my paddles in the left port for some 'You-can't-just-call-it-G.I Joe-because-it-has-a-giant-snake-in-it-which-makes-even-less-sense-when-it's-localised-as-Action-Man-in-the-UK-which-has-no-references-to-Cobra' action so it would skip past the title screen and the keypad seemingly worked fine. I then swapped the paddles for the joypad and the keypad now just crashes everything when pressing one of the item-change keys. I put the paddles back in and..... still crashes. Ugh, how many Super Mario Bros. cartridges do I have to sacrifice to the Atari gods before they reveal to me the secrets of the keypad controller?

 

Another thing which is a bit of a bummer is that I'm working on getting the password feature finished because it's been half there for a while and it would be nice to know how little RAM I have left to keep track of progress. The player's stats don't actually require a lot of space to record, the problem is the 12 bytes of flags recording what the player has picked up. At the moment, for an uncompressed password I'm going to need 31 character passwords and for compressed.... 29 characters. That firmly pushes the amount of data I need to store past the 25 bytes allowable by 7800BASIC's HSC/Savekey routines.

Edited June 16, 2018 by SmittyB

[RevEng]

Another thing which is a bit of a bummer is that I'm working on getting the password feature finished because it's been half there for a while and it would be nice to know how little RAM I have left to keep track of progress. The player's stats don't actually require a lot of space to record, the problem is the 12 bytes of flags recording what the player has picked up. At the moment, for an uncompressed password I'm going to need 31 character passwords and for compressed.... 29 characters. That firmly pushes the amount of data I need to store past the 25 bytes allowable by 7800BASIC's HSC/Savekey routines.

You can always save/load using 2 different difficulties. That will give you twice the space.

[+SmittyB]

Ah, I didn't realise it was 25 bytes per difficulty. I assumed that was what would be allocated in total and then the difficulty selections each taking a piece of that. In that case at least saving will work even if I don't have a savekey to take advantage of it (or properly test it but I'm sure you'll all help with that when it comes to it).

 

As it is I think the way saving passwords will have to work for those using a savekey and a second joystick or keypad (if I can get the damned thing working reliably) is to have the controller plugged in to play, then when you want to quit go back to the titlescreen and make a note of your password, turn off the 7800, swap out the controller for the savekey, turn it back on, enter the password to continue, walk back onto the checkpoint to save, then turn off the 7800 and continue with your day.

[Trebor]

...I don't have a savekey to take advantage of it (or properly test it but I'm sure you'll all help with that when it comes to it)...

 

 

AtariVox present for testing and ready to go when needed with SotA.

[gambler172]

Hi Smitty

have Atarivox and Savekey for testing

[+SmittyB]

It's finally happened. The keypad is working as good as I want it to (on PAL at least).

Your luck stat will show the keypad number being registered with 1 and 4 being next / previous left item, 2 and 5 being next / previous right item, and 10 being pause. The only 'issue' I'm aware of is that if the keypad isn't plugged in it will register key 11 until one is plugged in when you can then unplug it and it will register 0 instead.

Please do what you can to test / break it because I'd like to be certain it works on NTSC as well as it does on PAL.

 

An imaginary high-five to anyone who prints their own snazzy overlay.

SotA NTSC Keypad.a78

SotA NTSC Keypad.bin

SotA PAL Keypad.a78

SotA PAL Keypad.bin

[Jinks]

Wow that looks great on your screen! Can't believe that is a 7800. Thought it was minecraft..

Edited June 19, 2018 by Jinks

[+SmittyB]

Normally it looks nothing like that with colours flashing all over the place, but because I turn off the colourburst in the HUD and when paused the TV will eventually realise that it shouldn't be doing that and shows the proper signal from the Atari.

 

My CRT does the same to a much lesser degree.

[+SmittyB]

While I'm at it I'd like to thank pboland for originally suggesting adding keypad support. It was definitely a good idea and I'm so pleased that it's finally working. It also means if I ever want to add keypad support to future games I have the code to do it.

 

I realised this morning that the key 11 bug is actually very useful. It means I can detect whether a keypad is plugged in at startup and then just skip checking it later on. I'll probably have to do that to avoid upsetting savekeys / atarivoxs and it's nicer than having to manually select using a difficulty switch.

That means I have 2 difficulty switches left over. Maybe I'll use them for selecting different keypad control schemes.

Edited June 19, 2018 by SmittyB

[+pboland]

While I'm at it I'd like to thank pboland for originally suggesting adding keypad support. It was definitely a good idea and I'm so pleased that it's finally working. It also means if I ever want to add keypad support to future games I have the code to do it.

 

I realised this morning that the key 11 bug is actually very useful. It means I can detect whether a keypad is plugged in at startup and then just skip checking it later on. I'll probably have to do that to avoid upsetting savekeys / atarivoxs and it's nicer than having to manually select using a difficulty switch.

That means I have 2 difficulty switches left over. Maybe I'll use them for selecting different keypad control schemes.

 

 

You did the work! I just made the suggestion. I thank you for making a game the uses the keypad controller. I always felt it was an under used peripheral that had a lot to offer. When I get time I will make up an overlay for your awesome game.

 

BTW, when you make this into a cart, I would love to purchase a copy.

[DracIsBack]

When this is done, I'm up for buying a copy as well. Wow!

[Trebor]

Smitty...I'll provide the keypad edition some good breaking testing under an NTSC console, hopefully sooner than later.

Worst case scenario being sometime this weekend.

[+SmittyB]

Simple loading from passwords is now in. Give it a code and it'll give you the right stats and items. I'll be adding the corresponding saving which should hopefully be enough to start testing the HSC/savekey support.

At the moment passwords aren't scrambled in anyway or have validation but I intend to add that once I know the basic saving/loading process works.

[gambler172]

Simple loading from passwords is now in. Give it a code and it'll give you the right stats and items. I'll be adding the corresponding saving which should hopefully be enough to start testing the HSC/savekey support.

At the moment passwords aren't scrambled in anyway or have validation but I intend to add that once I know the basic saving/loading process works.

Hi Smitty

 

sounds good....now we need a level for testing.....my savekey is hot....

[+SmittyB]

Saving via passwords is now in and appears to work fine, but they're mostly zeroes so it's very easy to just modify your password to amend your state if you feel like doing so.

I've hit a snag in that I need to rewrite yet more parts in assembly to free up enough ROM to add the HSC and savekey support so that probably won't be in for a while.

[Trebor]

Smitty...The keypad inputs are working perfectly under an NTSC console. I haven't been able to break it (yet).

 

For the record, I have been utilizing a Video Touch Pad, much like yourself.

[+SmittyB]

Very nice Trebor, thanks. That should mean any keypad style controller should work, and if it doesn't it's probably the console having the problem.

 

I think I've got saving to HSC working according to emulation but I can't really tell because there's an issue with loading where the password shows as all zeroes until you press a button to continue where it flashes the correct password for a single frame but acts as if one wasn't entered.

[+SmittyB]

Saving to HSC is now working according to MAME. I've made a minor adjustment so it's the password data rather than the password itself that gets saved, meaning it's all saved in 20 bytes. I think there's still a couple of bugs but I'm sure it's with what data I'm saving rather than how I'm saving it.

 

Am I right in thinking 7800BASIC does its own checks to see if a HSC or savekey exists before trying to output anything? I'm just trying to get an idea of what checks I need to do to make sure the keypad and savekey don't interfere with each other.

Edited June 26, 2018 by SmittyB

[RevEng]

Am I right in thinking 7800BASIC does its own checks to see if a HSC or savekey exists before trying to output anything? I'm just trying to get an idea of what checks I need to do to make sure the keypad and savekey don't interfere with each other.

You're correct. 7800basic does some checks during the game boot, and it sets "hsdevice" accordingly: 0=no device, 1=High Score Cart, and 2=AtariVox/SaveKey

[gambler172]

Hi Smitty

now the keyboard works.....

and now,we need to check some save options.

greetings Walter

[+SmittyB]

At the moment I'm working on adding all the usable items and abilities, or at least placeholders, for the sake of testing to make sure all items are saved and loaded. I've noticed a bug with the passwords where if I have all items and save the password contains a 'G' when the values are 0 to F in hex but it seems to work regardless so it might just be a graphical problem.

[+SmittyB]

I've got to say that it's becoming a real slog to rewrite chunks of code to make more room to fit more content in. I can't wait to finish this so I can move on to something simple and fun that doesn't take 2 years to make. Eurgh.... I'm just glad I can vent here enough to get on with things.

[+SmittyB]

I've had a ROM-saving epiphany today and I think I'll need your help realising it.

I have a significant number of lists in my game where I need to call different subroutines based on the value of something, at present the way I'm doing this is with overly long reams of comparisons such as:

;---Slime---
	CMP #objectIDSlime
	BNE .skipActSlime
	JSR .basicEnemyAct
	JMP .objectsActSkipLoop
.skipActSlime

;---Pnydt---
	CMP #objectIDPnydt
	BNE .skipActPnydt
	JSR .basicEnemyAct
	JMP .objectsActSkipLoop
.skipActPnydt

;---Cultist---
	CMP #objectIDCultist
	BNE .skipActCultist
	JSR .basicEnemyAct
	JMP .objectsActSkipLoop
.skipActCultist

I realised that instead I could just the value of whatever I'm comparing (the objectID in the above example) and use it as an index into a pair of lists to get the high and low bytes for the routines I want to jump to, then indirectly jump to that address. It means I'll have to jump back to a specific point in the code rather than to wherever the routine was called from but I don't think it's a situation that exists in my code so far.

 

So far I have these long comparisons for choosing:

Which item was used in the left hand

Which item was used in the right hand

Which item to draw in the left box

Which item to draw in the right box

Which objects need to act each frame

Which objects need to be drawn at distance 2

Which enemies need to be drawn at distance 2

Which objects need to be drawn at distance 1

Which enemies need to be drawn at distance 1

Which objects need to be drawn at distance 0

Which enemies need to be drawn at distance 0

Which compass direction to draw

Which objects to set up when loading a map

Which sound to play when requested

Which map to load

 

So you can imagine this is just all wasted space in ROM. I'm going to try rewriting a couple of these and hopefully that will free up all the space I need to make the rest of this project relatively plain sailing. If I'm unsuccessful I'll be sure to beg for advice.

[+SmittyB]

Success! I've replaced the 'Which item was used' lists with new tables and I've gone from 77 bytes free with just the left hand list in place and not enough space to add the right hand one, to 182 bytes free with both lists in place.

Very promising when they only have 24 entries each and so weren't as obviously inefficient as some other lists.

 

~Addendum~

I've just given my HUD item drawing lists an overhaul too and...... saved a whole 1K in my main area and another 200+bytes in a DMA hole, and everything is noticeably running faster so I must have been introducing some slowdown with it. I wish I had thought of doing this sooner.

Edited July 17, 2018 by SmittyB