Jump to content

Recommended Posts

Posted (edited)

EDIT: Current release 4/25/20 can be found here

 

Hello! Long time no see!

 

Due to the coronavirus outbreak my schedule has conveniently been freed up, and I've started to port VePseu to the TI-99/4a! Attached is the progress so far..

 

Kinda sad I couldn't make a raster engine like BUILD or DOOM, but floating/fixed point is kinda a pain to implement and multiplication/division isn't signed like addition/subtraction, so I didn't feel like tackling that beast just yet. Is it possible? more than likely. Would it be playable? Not so sure

 

The cart limitations are very similar to the original VeSpeu, in that I aim to keep the whole shebang under 4k. The code I'm working with also uses the upper 4k of the cart for RAM (specifically, as a video buffer so we don't have to access the slow VDP to manage basic graphics, you'll see why). The basic render code is done and only takes up around 1520 bytes *including an uncompressed map. I also plan to implement basic RLE or possibly simplified gzip compression on the maps as well, i'll just need to see how that goes..

 

Here's the basic to-do list

  1. Optimize code so it can run at 60/50 fps
  2. Comment the code
  3. Code Java-based development tools for maps, sprites, etc.
  4. Implement basic compression
  5. Make walls prettier
  6. Increase map size from 16x16(maybe, depends how tight optimization has to be)
  7. Minimap(maybe, depends if I have trouble moving through maps. Colored walls are a thing now)

 

I do tend to have a habit of not finishing projects, I'm aware of this, but I still plan on optimizing the code a little and commenting the code before releasing the source.

 

The TI-99 does have a lot more room to implement a game compared to the Atari 2600, and I already have a few in mind :) The source will be licensed under the BSD 3-Clause Revised license, and I'd love to see a game or two made with it!

 

Plan on the code/binary to be released within a day or two, but don't quote me on it...

vepseu99.png

vepseu99_4_25_2020_1.png

vepseu99_4_25_2020_2.png

Edited by Gip-Gip
Added pictures
  • Like 7

Share this post


Link to post
Share on other sites
Posted (edited)

There was a lot of commenting I had to do! Specifically getting the cycle count for the renderer took 6 hours of calculations, zoning out, and coffee breaks. Not fun, and not really that accurate, but I'd say necessary

 

I got basic comments and optimization fixes done today, and it works well enough to where I feel good making the source officially open, the GitHub page can be found here.

 

You'll need Win994/a or another emulator that supports binary carts, or a FinalGROM 99

 

Controls are as follows:

  • W - move forward
  • S - move backward
  • A - turn left
  • D - turn right

 

I'll be making more optimizations over the next few days, however I'm primarily concerned about code readability. If a piece of the code stumps you, or you just can't follow it, tell me and I'll try to change that in the source.

 

Nonetheless, I have little hope the frame rate will go higher than 20. Not that it actually matters though, movement's not smooth within the slightest.

 

Current to-do list

  1. Optimize the code for size
  2. Continue to improve code readability
  3. Code Java-based development tools
  4. Implement basic compression
  5. Make walls prettier

Looking forward to seeing what everyone thinks!

Edited by Gip-Gip
  • Like 2

Share this post


Link to post
Share on other sites
1 hour ago, Gip-Gip said:

You'll need Win994/a or another emulator that supports binary carts, or a FinalGROM 99

 

To my knowledge, all of the emulators/simulators support binary cartridges, though I am not sure how you flag part of the cartridge ROM space (>6000 – >7FFF) as RAM. Cartridge RAM implementation is likely different for each one that allows it. I suspect they all do allow it because I am pretty sure they all support the MiniMemory cartridge, which has RAM in cartridge space. Others with the requisite knowledge should be along shortly.

 

...lee

  • Like 1

Share this post


Link to post
Share on other sites

You should be able to save some clock cycles by moving two consecutive bytes to the VDP and then clearing a word of the screen buffer with a single CLR *A3+ (start with LI A3, SCRNBF).

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)
11 hours ago, Lee Stewart said:

 

To my knowledge, all of the emulators/simulators support binary cartridges, though I am not sure how you flag part of the cartridge ROM space (>6000 – >7FFF) as RAM. Cartridge RAM implementation is likely different for each one that allows it. I suspect they all do allow it because I am pretty sure they all support the MiniMemory cartridge, which has RAM in cartridge space. Others with the requisite knowledge should be along shortly.

 

...lee

I think the only standard is the one used by FinalGROM 99, which is to set the 4th byte of the cart header to R (or >52). That's also what @Gip-Gip has used, so maybe it's an option in WinAsm99? https://js99er.net emulates this flag, so the binary cart in the VePseu github repository works in my emulator, and also with the FinalGROM.

Edited by Asmusr
  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, Lee Stewart said:

 

To my knowledge, all of the emulators/simulators support binary cartridges, though I am not sure how you flag part of the cartridge ROM space (>6000 – >7FFF) as RAM. Cartridge RAM implementation is likely different for each one that allows it. I suspect they all do allow it because I am pretty sure they all support the MiniMemory cartridge, which has RAM in cartridge space. Others with the requisite knowledge should be along shortly.

 

...lee

 

Win994/a has a little checkbox to enable 4k ROM/4k RAM carts, i just didn't know if it was a thing on other emulators. That and the semi-standard ASCII "R" for ram-mode is also in code, as @Asmusr pointed out

 

6 hours ago, Asmusr said:

You should be able to save some clock cycles by moving two consecutive bytes to the VDP and then clearing a word of the screen buffer with a single CLR *A3+ (start with LI A3, SCRNBF).

 

It save quite a few! Not only was there a slight error in my calculations for RNDPSH, meaning RNDPSH took up even more cycles before, but your optimization saved around 11k+ cycles. Doesn't seem like much, but now it only takes around 2 frames to render instead of 3!

  • Like 2

Share this post


Link to post
Share on other sites
Posted (edited)

Some related links:

 

I remember we discussed 3D engines a few years ago:

 

Living Tomb is a fine example of a "3D maze" game, but I never managed to get very far in the game (can you see your stats anywhere?😞

http://tigameshelf.net/asm.htm (scroll to bottom of page)

 

I also made a raycaster for the TI-99/4A, using the capabilities of the F18A video board. Still hoping to improve that when the F18A MK2 is relased: 

 

 

 

Edited by Asmusr
  • Like 2

Share this post


Link to post
Share on other sites

Classic99 maps all CPU memory as RAM then replaces only what you load with ROM, so as long as the BIN is only 4k it should "just work". Set the end of the filename to "C.BIN" for autodetection (ie: MazeC.bin) or create a Classic99.ini entry.

 

  • Like 1

Share this post


Link to post
Share on other sites

Wouldnt that assume he's not trying to use some kind of banking technique, and just using 4k of RAM at the bottom of the cart space?

Share this post


Link to post
Share on other sites
19 minutes ago, wierd_w said:

Wouldnt that assume he's not trying to use some kind of banking technique, and just using 4k of RAM at the bottom of the cart space?

It's just an 8K cart.

Share this post


Link to post
Share on other sites

As a testament to how much easier java is compared to assembly, I'm already near finished with a basic map editor and it's taken me the same amount of time it took to comment render.asm. I'll probably have the program out before I go to bed

vepseutool_4_7_2020.PNG

  • Like 1

Share this post


Link to post
Share on other sites
2 hours ago, wierd_w said:

Wouldnt that assume he's not trying to use some kind of banking technique, and just using 4k of RAM at the bottom of the cart space?

It would if I hadn't looked at the code to determine that before I posted. ;)

 

  • Haha 1

Share this post


Link to post
Share on other sites

Alright! I finally have a JAR for the map editor that you can run! Source code releasing when I'm less tired :sleep:

 

https://github.com/Gip-Gip/VePseu99/raw/master/tools/vepseutool.jar

 

Left click to place a wall

Left click + shift to delete a wall

Right click for the options menu

Middle mouse to drag the grid around

Scroll to zoom in/out

Ctrl+S to save

 

You can't load files yet, or really much else for that matter.

 

To use the map with the VePseu99 source, save over the maps.a99 file (make a copy of that if you want), type "MAP1" at the very start of the file, and assemble as normal. If you couldn't tell, I just wanna get this out so I can go to bed :-D

 

Also, @Asmusr, sorry for not checking out the thread about TI-99 renderers like I should've, I'll do that tomorrow

 

Feedback and suggestions are, as always, appreciated

Share this post


Link to post
Share on other sites
6 hours ago, Asmusr said:

Some related links:

 

I remember we discussed 3D engines a few years ago:

 

Living Tomb is a fine example of a "3D maze" game, but I never managed to get very far in the game (can you see your stats anywhere?😞

http://tigameshelf.net/asm.htm (scroll to bottom of page)

 

I also made a raycaster for the TI-99/4A, using the capabilities of the F18A video board. Still hoping to improve that when the F18A MK2 is relased: 

 

 

 

Nevermind I couldn't sleep

 

I'm legitimately impressed there's already a 3d renderer on the TI. Kinda wish I stuck with the raycasting idea, maybe at a later date I'll retrofit a raycaster into the code.

 

It does upset me a little that the TI is really the only 8-bit era computer to be lacking in the 3d-department.

Share this post


Link to post
Share on other sites
Posted (edited)

@Asmusr So quickly hacked a raycaster into VePseu, then I broke it

 

It's not fast by any means, and it kinda sucks at this resolution, so I don't think I'll continue developing it. I have the uncommented source code and binary in the zip attached, if you want to use the SIN and COS tables and implement something that works, feel free man. The concept's pretty basic within itself, make a normal raycaster with the coordinates multiplied by 256(to supplement the lack of fixed or floating point numbers), then when you want to read from the map divide everything by 256. I suck at implementing this idea, and even then it's still too slow to play any shooter games or maze games, in my opinion.

 

With VePseu99 I think I'll instead try to make it more RPG-focused. Make it easy to chain maps together to make one big map, have a more RPG-like combat system, etc. etc. 

VePseu99.zip

Edited by Gip-Gip
Emphasizing the fact I broke my renderer, so people understand why it doesn't work properly
  • Like 4

Share this post


Link to post
Share on other sites
Posted (edited)

VePseu99 4/8/20 is official! GitHub link here and binary attached for quick-download

 

Changelog includes:

  • Fixed wall colors so they change when the player rotates
  • Implemented RNDPSH optimization suggested by @Asmusr
  • Added VePseuTool map editor and it's source to the repository
  • Modified the demo map

I didn't comment the VePseuTool source that well, but I'm not sure that many people care about that code much. Feel free to tell me otherwise :P

 

main.bin

Edited by Gip-Gip
  • Like 3

Share this post


Link to post
Share on other sites

Just implemented LZ-like compression for maps, it doesn't compress it super small but any compression is good compression! That and even if it only halves the map size, assuming we have 2k dedicated to maps that's 16 maps in total compared to 8 you'd normally get!

 

Next on the checklist, entities and sprites!

  • Like 1

Share this post


Link to post
Share on other sites

VePseu 4/14/2020 is out! GitHub is here and the binary is attached!

 

Changelog includes:

  • Added "textures" and colored walls
  • Added LZ-like compression for maps
  • Modified the demo map
  • Reorganized the source to make building easier (on windows)

Keep note commenting is not up to date as I am currently trying to implement other big features

 

Also, VePseu99 does not assemble with xas99, as far as i know

vepseu99_4_14_2020.PNG

vepseu.bin

  • Like 3

Share this post


Link to post
Share on other sites
Posted (edited)

Just added "scenes"! Basically, entities except they project sprites on the screen and prompt the player with choices. I have a basic door example in the binary below

 

Tomorrow I'll tidy up the code and the day after that I'll add VePseuTool functionality

vepseu99_4_15_2020_1.PNG

vepseu99_4_15_2020_2.PNG

vepseu.bin

Edited by Gip-Gip
  • Like 6

Share this post


Link to post
Share on other sites

Currently adding visual editing for scenes in VePseuTool, so you can move the sprites freely around and see how they look combined with all the walls and such. Still have a bit of work to do to get it implemented but I'm getting there

vepseutool_4_16_2020.PNG

  • Like 3

Share this post


Link to post
Share on other sites

I like the 'textures'. But I'm also thinking about how it could be improved. If you limit to 4 or 8 directions and only 32 columns a simple ray-caster might be possible. Then you could see more frames when you move between squares. I don't know from your code how the current algorithm is working. Perhaps you could write a few notes?

Share this post


Link to post
Share on other sites
17 hours ago, Asmusr said:

I like the 'textures'. But I'm also thinking about how it could be improved. If you limit to 4 or 8 directions and only 32 columns a simple ray-caster might be possible. Then you could see more frames when you move between squares. I don't know from your code how the current algorithm is working. Perhaps you could write a few notes?

I'm not the best explainer but I'll try

 

Basically, both VePseu and VePseu99 work off a hybrid raycaster/raster algorithm, sorta. There's the wall list. Each entry in the wall list contains the relative location(to the player) of a wall to look for, along with the graphics to draw if the wall exists. When rendering, we go through the wall list and for each entry look at the given location for a wall. If there is a wall, the wall is drawn. Simple as that. (I'll go through the process step-by-step in the readme once I get the time)

 

Now, this is incredibly simple and fast as far as "3d rendering" goes; I'm willing to bet $10 it's the fastest software rendering algorithm out there. That being said, it is incredibly limited as far as graphics go. You're stuck to the 4 cardinal directions, and you can only move 1 wall at a time, no more, no less.

 

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

 

Don't even get me started on raster engines, implementing one of those with the TI's lack of floating point and signed multiplication/division is a lost cause, and should never be attempted lest the programmer goes insane

  • Like 1

Share this post


Link to post
Share on other sites

Almost done with programming everything for the tool, hopefully everything works and works well so I can start developing a game!

 

The source code went from being xas99 incompatible to relying on xas99 macros, and I will have Linux and windows build scripts

 

Anything else you guys think I should add before I push the next update?

  • Like 1

Share this post


Link to post
Share on other sites
On 4/18/2020 at 11:11 AM, Gip-Gip said:

Don't even get me started on raster engines, implementing one of those with the TI's lack of floating point and signed multiplication/division is a lost cause, and should never be attempted lest the programmer goes insane

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 ][)

 

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.

 

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.

 

 

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...