Spire of the Ancients (WIP)

[+SmittyB]

Ahhhh I see. That's cleared up some confusion I've had about the indirect modes since I first read up on them. I've never found a good example to explain it before.

 

I wish I could like your post more than once. 11/10, 3 thumbs up.

[gambler172]

Ahhhh I see. That's cleared up some confusion I've had about the indirect modes since I first read up on them. I've never found a good example to explain it before.

 

I wish I could like your post more than once. 11/10, 3 thumbs up.

Hi Smitty

 

Show us your Progress...cannot wait to Play....

[+SmittyB]

You'll have to wait a while longer, there's really nothing new to see. It's all background changes.

[+SmittyB]

Using some of the spare RAM from compressing the map data I've now added a particle system I've been wanting to put in for a while. This is just to add a little extra something here and there such as dust falling when you go down a pit or the occasional drop of water, but mainly for combat to show something like a blood splatter when damaging enemies or getting hurt yourself.

 

It has no depth as it's the last thing drawn, but it means the game won't prioritise drawing a particle over something important and I can throw around a good few of them without much of an issue. I've included a quick GIF which doesn't really do it justice.

 

Edited February 10, 2019 by SmittyB

[Heaven/TQA]

Cool. Looks good. Me struggling with DLs and DLLs and I see how easy it seems with Basic

[+SmittyB]

Cool. Looks good. Me struggling with DLs and DLLs and I see how easy it seems with Basic

 

Using 7800BASIC is one of the best decisions I've made in years. I could have fumbled some single-screen game together in assembly but there's no way SotA would exist without it.

[+SmittyB]

Well the '3d' sound is in and working fine as far as I can tell. I've also prevented everything from slowing down when there are a lot of enemies in their idle state due to everything trying to look for the player every frame which is a long time overdue.

 

Now I've hit an interesting bug where according to the MAME debugger (why haven't I been using this all along?) the CPU is executing some graphics data as code and hitting a bad value. Now to try and work out how the hell it's getting there.

 

 

 

Edit:

And just like that I can't replicate it any more. Is it fixed? Was there ever a bug to begin with or was it my imagination? Who knows?

 

Edit edit:

Also discovered and fixed a bug where enemies would sometimes not be drawn at distance 2 (visible distances are 0,1, and 2).

Edited February 16, 2019 by SmittyB

[+SmittyB]

The blind and deaf statuses are in and functioning. They each have a value that is the strength of the effect and they heal at a constant, fixed rate.

Blindness essentially darkens the room so light sources can still make it easier to see, but the effect can easily stack to the point where the room can be fully bright, and you can be holding a torch, but still can't see.

The deafness effect stacks in the same way and effectively uses the new sound routines to make things quieter. While the effects aren't as obvious as blindness it means you can't as easily perceive where things are relative to you.

 

I intend to also add poison, but I'm almost unsure about the confusion status. Confusion will have a chance (based on the strength of the effect) to randomly turn when you try to move, so you may have meant to walk forward but instead turn left. I'm very aware that taking control away from the player is usually not fun, and also if it has no in-game consequence except to annoy the player then that's also not fun.

 

 

Edit:

I've got poison and dizziness (thought it was more fitting than confusion) working. Poison deals damage over time and the amount of damage increases based on the strength of the effect up to a possible 19 damage per tick, though you'll only last a couple of seconds from full health with that much damage.

The dizziness effect has an X in 64 chance to trigger where X is the strength of the effect, then it's 50/50 as to whether you turn left or right.

 

 

I guess I'm just on fire today for getting old ideas implemented

Edited February 16, 2019 by SmittyB

[Trebor]

...I guess I'm just on fire today for getting old ideas implemented

 

*Hopes Smitty remains on fire*

[+SmittyB]

So while on a roll I decided that the scrolling floor effect on the titlescreen was nice 'n' all but I figured I could do better. The last thing I programmed before getting into the 7800 was a voxel renderer (here's a good explanation for those who don't know what I'm talking about https://s-macke.github.io/VoxelSpace/) so my thought was that I could do the same thing on a 7800, but essentially rendering only 1 column which would be the buffer for the background colours.

 

It took a couple of days experimenting to understand what I needed to do to make it work with 8-bit unsigned values as the maths involved normally just goes into large negative numbers but I got there in the end. There are still a few problems with voxels that are too tall not being rendered where they roll under zero but that's not a problem.

 

I haven't optimised it so it runs very slow so I recommend turning off the frame rate limiter to test it. Left and right move you forward and backward a voxel at a time, and up and down change the height of the camera. The landscape is mostly flat but I intend to render a nicer one with shadows baked into the colour data, and I'm going to see if I can use 16 bit maths to get a larger map so I can squeeze in more detail and have the map loop less frequently.

 

In the game itself the spatial sound effects are in. The sword is set to test the particle effects, the hammer will poison you if used in the left hand and make you dizzy if used in the right, and I've randomised the slime colours to see if it might look good.

That spontaneous crash is still present so I'll have to hunt that down.

 

This is a very rough build as I've only just made a breakthrough on the voxel part and wanted to share it. It might seem like a waste of time putting this much effort in when the effect I had before worked fine, but I have many ideas for future projects and this is almost like a proof of concept. Plus a titlescreen gives a first impression and I want it to be a good one, I want somebody to be entertained by it instead of it just being a screen saying 'Press Fire to Play'.

SotA.bas.a78

[Iwantgames:)]

wow! looking awesome. i can see myself loosing many hours to this when completed

 

great work!

 

edit - oh for anyone wanting to try it, i couldnt get it to work with prosystem emulator but works great with the bupsystem emulator

Edited February 20, 2019 by Iwantgames:)

[CrazyChris]

I'm using BupSystem, but part of the bottom of the screen, is wrapping around to the top?

[Trebor]

I'm using BupSystem, but part of the bottom of the screen, is wrapping around to the top?

 

Issues with BupSystem's visible output has been mentioned in another thread. Screenshot examples from some retail games are in the aforementioned link spoiler(s). Commando appears similar to what is happening with SotA.

 

BupSystem currently shows overscan areas that are typically not seen on a display. The average should be 8 scanlines not visible ('cut') from the top and bottom of a screen (224 lines instead of 240); same as the other contemporary consoles of the time.

 

Also, see point number 3, "Game Visibility Issues", from TailChao's response.

[CrazyChris]

 

Issues with BupSystem's visible output has been mentioned in another thread. Screenshot examples from some retail games are in the aforementioned link spoiler(s). Commando appears similar to what is happening with SotA.

 

BupSystem currently shows overscan areas that are typically not seen on a display. The average should be 8 scanlines not visible ('cut') from the top and bottom of a screen (224 lines instead of 240); same as the other contemporary consoles of the time.

 

Also, see point number 3, "Game Visibility Issues", from TailChao's response.

Trebor,

 

Thanks for the detailed info!

[+SmittyB]

I think I have found and fixed the cause of the random crash. In short it seems that under the right circumstances it was possible for new data to be written to the sound buffers before the old data was terminated, effectively skipping into another set of sound data and doing its thing. Since removing some old POKEY test data that shouldn't normally be touched I haven't been able to replicate the issue where I could trigger it fairly frequently before.

[+SmittyB]

Gah! Nope the crash is still present even after making sure I'm zeroing all data in the sound buffers after the sound I want to play.

I'm assuming there's no way to step back an instruction in the MAME debugger, that would be incredibly useful right now. The problem I have is that I don't know 100% what triggers the crash, recreating it is too unreliable, and stepping through every instruction for a good 2 or 3 minutes until it crashes (and hoping I pick up on the instruction that crashes it) is a bit crazy.

[RevEng]

There's no backwards stepping in the MAME debugger, but you can use trace to log all executed instructions to a text file. If you stop the trace shortly after detecting the crash, you should be able to read backwards through the log to figure out where it went off the rails.

 

You might also try the "quality check" part of the linked doc. You might get lucky.

[+SmittyB]

That's helped me piece together the final moments. It's failing as soon as it tries to return from servicesfxchannelsdone as (in this case at least) it's jumping to 9B45. So now I need to walk back through and try and figure out why the stack is out of whack.

[+SmittyB]

Right.... I think I've finally got that bug squashed, I still don't know the exact cause but the solution was to use different temp variables. It looked to me like it was being triggered when copying to the sound buffer was split over 2 frames with the general 7800BASIC routines running in between so one of us was modifying what the other was using.

 

I've also added a screen-shake effect when you take damage. It only shakes the walls, the wall graphics don't extend past the normal visible area, and the objects on top stay in their normal position at the moment so it doesn't look amazing but it gets the point across. I don't want to make too many objects move with the screen as that's just extra time needed to draw them, but I think I will for things like ladders, pits, and torches.

The screenshot highlights these problems, you can see the background on the right and the pits in the background aren't in the right place so it breaks the illusion of depth (please ignore the dodgy colours of the hole in the ceiling on the top left).

 

[+SmittyB]

A lot of good progress has been made this week so far. I've been polishing up a few things and that got me thinking about Rikki & Vikki's 2-button joystick check.

 

If reading a 1-button joystick as a 2-button joystick is potentially damaging, is the same true if a 2-button joystick is plugged in and read as a 1-button joystick?

 

SotA requires a 2 button controller in the left port but the right could be a 1 or 2 button controller, a keypad, or a savekey / AtariVox so I'm considering adding a soft-lock if the left stick isn't correct, and setting the right stick to 1-button mode at the start and leaving it as such. I know the keypad works fine in 1-button mode and I'm assuming the AtariVox will be too considering it works on the 2600, so it's really a question of whether I can safely ignore 2-button joysticks seeing as I won't be doing anything with the buttons.

[RevEng]

If reading a 1-button joystick as a 2-button joystick is potentially damaging, is the same true if a 2-button joystick is plugged in and read as a 1-button joystick?

Nope. Reading a 2-button stick with 1-button mode code is not a problem.

 

BTW, 7800basic has protection in it's main loop for the harmful read 1-button with 2-button code case. If the player plugs in a single-button joystick, the 2-button mode will be disabled for the rest of the session.

[+SmittyB]

Thanks, good to know.

[SlidellMan]

I think you may be in the process of making the 7800's own Megami Tensei. (Considering that it was a first-person dungeon crawler.) By the way, I thought of some enemy ideas if you're interested.

[+SmittyB]

Thanks for the offer, but as it is I'm having to shuffle the graphics around for the enemies I do have. With palette swapping and reusing graphics I think I've got an adequate variety though of course it's regrettable that I couldn't add more.

 

 

The reason it's been a few months since my last update is because I've been working on and off to bring things up to a point where I can release a sizeable demo for people to try out and play test while I work on finishing things.

I'm not there yet but there's a lot more polish compared to my last posted build including but not limited to:

A credits screen

A special thanks screen

An enemy viewer I intend to make unlockable after completing the game

The completed pseudo 3d voxel map on the title screen

A redone title theme

Text screens for the story when starting a new game and finishing

More particle effects

Player projectiles including a fireball that can ignite unlit torches and lights up the map slightly while it's in flight

Better level mechanisms including a portcullis that can be raised and lowered with switches in combination with other mechanisms

 

[gambler172]

Sounds good.......now i want to see the demo ?

 

greetings Walter