VePseu 99

[Gip-Gip]

Done implementing scenes more or less! I'll make a map demo'ing the features tomorrow. If you want to check out the features immediately, go to the unstable branch on github

 

On 4/22/2020 at 6:15 PM, FarmerPotato said:

I like your rendering engine so far. It does at least as much as Tunnels of Doom, and it's snazzier than dungeons in Ultima 3 (on apple ][)

Thanks!

 

On 4/22/2020 at 6:15 PM, FarmerPotato said:

What would it take to subdivide the grid, adding finer resolution? Instead of 2:3:7:3 sized wall segments, maybe draw 1:1,1:2,3:4,3.

 

Not much at all, but it *would* increase the render time and decrease the available map space exponentially. Not saying I won't do it, but I don't yet see a reason why yet

 

On 4/22/2020 at 6:15 PM, FarmerPotato said:

And can it be graphic chars? A set of 8 progressively darker (more black pixels) tiles would do a lot to create depth. The diagonals would not look as pretty though.

 

Not exactly sure what you mean by this...

First, if you mean 8 different shades of colors, that's physically impossible on stock TI hardware. We have at most 3 shades of each basic TI color to work with.

Second, if you mean dither the walls the farther they are from the player, that could actually work, maybe, but also it would still add to the size and complexity of the code and

completely remove "textures" from the game since instead of 8 textures we'd have 8 dither levels. It would add some depth though..

 

17 hours ago, Elia Spallanzani fdt said:

Maybe add a little sound of footsteps?

 

I was actually planning to do that next! I plan to add support for sound effects and I *want* to add the ability to import MIDIs in VePseuTool.

[Asmusr]

On 4/18/2020 at 6:11 PM, Gip-Gip said:

Now, contrary to what you may think, limiting a raycaster to 8 or 4 angles wouldn't really benefit framerate. You still need SIN and COS to calculate the ray angles, and just adding the player's angle to the ray's angle is an effective way to look around.

 

A raycaster could be implemented, but implementing one that runs at a 10+ framerate consistently would be a challenge, and probably wouldn't leave much room for the rest of the gamecode to run. That's why there are no games made with the original VePseu; while it was pretty cool to have a 3d engine on the Atari 2600, there was no room in the engine for an actual game

I have given this some thought, and I think a frame rate close to 10 would be possible with 32 rays/columns. However, it would require more than 8K space because some things would have to be pre-calculated. I think I may give it a try... 

[Gip-Gip]

Almost done toying around with the level editor! Gonna have to call it quits for tonight, but here's a sneak peak of what's to come

[Gip-Gip]

Finished making a demo map! I'm going to clean the source code up a bit, but until then I have the binary ready for anyone who wants to test it out!

vepseu.bin

[Gip-Gip]

Alright! VePseu99 4/25/2020 is official!

 

Changelog includes:

• Added scenes
• Added sprites
• Added actions
• Redid testmap

If you wish to check this stuff out for yourself visit the github or download the binary above, no code as changed since this morning

 

Apologies since my comments are fairly out of date now, I've been getting so excited implementing other features that I haven't really bothered keeping the source readable :/

 

Next on the to-do list, music, sound effects, along with a main menu! Also bankswitch support, since maps are now substantially bigger

 

Also, out of curiosity, has anyone other than me used VePseuTool?  

[sometimes99er]

Apparently seems to be locking up with Classic99. Tried earlier version (of your game). Same thing.
 
Works with JS99'er. Played it through to the end (took 1 minute). As an early demo, it's nice. When I "Reset" and choose the game again, it seems to be locking up.

 
 

[Asmusr]

1 hour ago, sometimes99er said:

Apparently seems to be locking up with Classic99. Tried earlier version (of your game). Same thing.
 
Works with JS99'er. Played it through to the end (took 1 minute). As an early demo, it's nice. When I "Reset" and choose the game again, it seems to be locking up.

 
 

It appears to be setting the VDP into 4K mode. So it doesn't work in JS99'er either if you turn off F18A emulation.

But another reason it may not be working directly in Classic99 is that it requires RAM at >7000->7fff. So I think you would need to set up a special configuration to run it.

[Tursi]

3 hours ago, Asmusr said:

It appears to be setting the VDP into 4K mode. So it doesn't work in JS99'er either if you turn off F18A emulation.

But another reason it may not be working directly in Classic99 is that it requires RAM at >7000->7fff. So I think you would need to set up a special configuration to run it.

Just need to not load ROM there. If you load Editor/Assembler, for instance, than that memory space is RAM.

 

(Edit) Tested it here and played through the whole thing in Classic99 - how are you loading it, Sometimes99er?

 

In order to make Classic99 treat it automatically as a cartridge ROM, I renamed it to vepseuC.bin, then loaded it simply by drag and drop.

 

[sometimes99er]

1 hour ago, Tursi said:

(Edit) Tested it here and played through the whole thing in Classic99 - how are you loading it, Sometimes99er?

 

In order to make Classic99 treat it automatically as a cartridge ROM, I renamed it to vepseuC.bin, then loaded it simply by drag and drop.

I renamed too (as you did), and loaded using the menu system. Also locking up if I drag and drop. And generally I've made no changes to the "classic99.ini".

 

5 hours ago, Asmusr said:

It appears to be setting the VDP into 4K mode. So it doesn't work in JS99'er either if you turn off F18A emulation.

Well, it worked/works for me. Clicked/click "Load Cart". Only the following is enabled: Sound, Speech, 32K RAM and 4 sprites per line limitation.

 

[Asmusr]

1 hour ago, sometimes99er said:

Well, it worked/works for me. Clicked/click "Load Cart". Only the following is enabled: Sound, Speech, 32K RAM and 4 sprites per line limitation.

You're right, the issue in js99er seems to be that the cart doesn't work after a reset. I must be forgetting to reset some part of the system.

 

In Classic99 QI3199.018 I get a the attached screenshot if a rename the file to vepseuc.bin and open it as a user cart (or by drad and drop).

 

It sets VDP reg 1 to >61, which I believe means 4K mode. If I patch byte >87 to >e1 it works in Classic99.

Edited April 26, 2020 by Asmusr
typos

[+mizapf]

Here is a MAME cartridge for it; I first had to find a suitable cartridge type, and best fitting was Mini Memory (but with normal RAM).

 

 

 

vepseu99.rpk

[Gip-Gip]

Also, I should add that is appears Js99'er is temporarily broken.. I was testing out adding footsteps and it appears sprites are being sent to the character table. I'll raise an issue and see if I can't fix it before they do

Edited April 26, 2020 by Gip-Gip

[Asmusr]

12 minutes ago, Gip-Gip said:

Also, I should add that is appears Js99'er is temporarily broken.. I was testing out adding footsteps and it appears sprites are being sent to the character table. I'll raise an issue and see if I can't fix it before they do

Actually it's me who have 'fixed' js99er to show the effect of running with 4K video memory. If you set VDP reg 1 to >e1 instead of >61 thus enabling 16K video memory everything should be fine.

Edited April 26, 2020 by Asmusr

[Asmusr]

2 hours ago, mizapf said:

Here is a MAME cartridge for it; I first had to find a suitable cartridge type, and best fitting was Mini Memory (but with normal RAM).

Does MAME ignore the 16K/4K flag in VDP reg 1?

[Gip-Gip]

3 minutes ago, Asmusr said:

Actually it's me who have 'fixed' js99er to show the effect of running with 4K video memory. If you set VDP reg 1 to >e1 instead of >61 thus enabling 16K video memory everything should be fine.

Huh. Well that was an easy fix

[Gip-Gip]

I'll have that out by the end of the day along with the sound stuff. Kinda hard for people to play my demo if it doesn't work with one of the more popular emulators 

[+mizapf]

2 hours ago, Asmusr said:

Does MAME ignore the 16K/4K flag in VDP reg 1?

 

Could be, yes.

 

Just checked: There is a long-standing comment at the file head "Todo:... Address scrambling when setting TMS99xxA to 4K".

Edited April 26, 2020 by mizapf

[Gip-Gip]

Here's the fixed cart with added audio. The code's getting pretty big and I'll do some size optimization later

vepseu.bin

[Tursi]

11 hours ago, Asmusr said:

You're right, the issue in js99er seems to be that the cart doesn't work after a reset. I must be forgetting to reset some part of the system.

 

In Classic99 QI3199.018 I get a the attached screenshot if a rename the file to vepseuc.bin and open it as a user cart (or by drad and drop).

 

It sets VDP reg 1 to >61, which I believe means 4K mode. If I patch byte >87 to >e1 it works in Classic99.

Yeah, that's a weird result. 018 is 6 versions back, so I can't really comment on what may have changed, though I didn't think I'd changed any VDP settings. It worked for me both with F18A on and F18A off.

 

I got exactly that when I turned off the 80 column hack.

 

[Tursi]

11 hours ago, sometimes99er said:

I renamed too (as you did), and loaded using the menu system. Also locking up if I drag and drop. And generally I've made no changes to the "classic99.ini".

 

Well, it worked/works for me. Clicked/click "Load Cart". Only the following is enabled: Sound, Speech, 32K RAM and 4 sprites per line limitation.

 

I guess based on what Rasmus is saying, trying enabling the F18A and see if that makes a difference? (If it really is the 4k bit, that will disable it indirectly as the F18A doesn't support that bit).

 

Ahhh, it works when I enable the 80 column hack. This disables 4k mode in the code.

 

So I'm not clear - does it or does it not work on hardware as-is?

 

[Gip-Gip]

Ok so I've started to implement bankswitching and it works pretty well so far, it's just a little complicated

 

Basically, the first bank is the standard code, nothing much has changed here. But every ROM bank past bank 1 contains a full map+scenes+code+music, and when LDMAP is called the map is copied into a second RAM bank. Then, the map data is copied into the first RAM bank to RAMMAP and the scenes/music stay in bank 2. ? 

 

Needless to say the implementation isn't perfect yet, and my code definitely needs some cleaning before I push it to git, but in theory this should be a fairly space efficient way to store maps. You can store 127 4kb maps in 1 rom, without any external add-ons. I'm pretty excited 

[Gip-Gip]

On 4/26/2020 at 7:15 PM, Tursi said:

I guess based on what Rasmus is saying, trying enabling the F18A and see if that makes a difference? (If it really is the 4k bit, that will disable it indirectly as the F18A doesn't support that bit).

 

Ahhh, it works when I enable the 80 column hack. This disables 4k mode in the code.

 

So I'm not clear - does it or does it not work on hardware as-is?

 

Apparently I didn't catch this yesterday

 

It should now, the newest binary should at least. It enables 16k mode instead of 4k

 

The 4k mode binary does not work on old hardware, however

[+mizapf]

Updated RPK for MAME.

vepseu99.rpk

[Gip-Gip]

14 minutes ago, mizapf said:

Updated RPK for MAME.

vepseu99.rpk 3.03 kB · 2 downloads

Thanks for providing RPKs 

 

I'll read up how to make RPKs next update I push an update

[+mizapf]

In fact, I pick an existing RPK and replace the dump file. You can re-use this one if your cartridge type does not change (4K ROM, 4K RAM); this is determined by the layout.xml inside. The RPKs are ZIP files with just the .zip suffix replaced by .rpk.

 

Maybe one day I'll add an RPK build function to TIImageTool.

 

I'd have added that earlier, but the point is, the RPKs should be obsolete and fully replaced by the common MAME ZIP cartridges. This plan is there for the last 10 years, but no one really came up with a concept how to handle homebrew stuff, and as long as this has not been settled, RPKs are here to stay. The arcade guys just don't think in terms of homebrew cartridges, and the other computer systems don't have this problem in the same way.

 

In the end it'll be up to me, I guess.