First person shooter on the TI? :)

[Bones-69]

I have had an idea for some time. Never seem to get around to putting my ideas into practice so thought I would share. This one seems like a doozy and maybe it is just too far out there.

 

I always imagined a first person type shooter for the TI99/4a, possibly even something that would run in XB or now perhaps potentially be XB Compiled (would require disk access though). My idea would be to make a simple world in 2D then have a program assemble the world in 3D. With character limitations the world would have to be quite basic. Maybe as complex as it can get would be just 3D blocks, or a hallway/Tunnel Of Doom type view, or maybe something like Atari Battlezone with very simple wire frame graphics.

 

My idea is to have a program assemble the players view in advance from every possible position of the game, along with every direction they can look and save each view to disc. Perhaps for the player to do a 360 turn it would require 8 different views (N,NE,E,SE,S,SW,W,NW) from every potential position in the game so every possible position would require 8 individual files or "screen shots".

 

Each of the thousands of potential views would be sent to a disc file and called everytime a player commands their character to move or turn. A single disc read for each file consisting of 252 characters would allow DISPLAY AT to create a player view measuring 9 x 28. More than enough space I think to make it interesting.

 

I am just throwing ideas around…. But say you had a game grid 100 x 100 and in that grid was “Blockworld”. Using emulation (because of physical disc space limitations), you could tell your trusty “TI 3D world creator” to start deciphering the 2D map and start writing files (the drawn images). Once file 80,000 was written you would have a 3D world with 1000 positions all with a view from 8 directions which could be explored. As updating the world during game play should be as simple as a single disc read and a DISPLAY AT statement, this would leave all remaining grunt to run sprite routines and give the world some action. The same idea could be used for pretty much any game where a first person perspective was required. Perhaps there is also some potential here for car racing games where a similar pricipal could be used to display the upcoming track...

 

I have to confess - I really wouldn't know where to start in regards to writing the program which initially creates and writes all the views. Would be a great challenge though!

 

Possible or just the result of too many late nights?

[sometimes99er]

Some nice ideas.

[TheMole]

I don't know how slow disk reads are (been ages since I've had the fortune of working on hardware), but accessing a new file each time you want to render a new frame will not get you anything near realtime enough for an FPS experience. A ToD style walkthrough, maybe...

 

For an FPS on the TI, I've always wondered if it would've been possible to get a wolf-style raytracer up and running in multicolor mode. I've seen one on the Apple II in their "low res graphics" mode. 64 single-hit ray calculations might be possible. Worth a try, might try to do something with the gcc compiler to check it out (although I assume it'll need assembler optimizations that gcc can't provide to be really real-time).

[+retroclouds]

Accessing the CF7+ (NANOPEB) should be quite fast & could be doable on the TI-99/4A.

Edited April 12, 2013 by retroclouds

[Tursi]

For an FPS on the TI, I've always wondered if it would've been possible to get a wolf-style raytracer up and running in multicolor mode. I've seen one on the Apple II in their "low res graphics" mode. 64 single-hit ray calculations might be possible. Worth a try, might try to do something with the gcc compiler to check it out (although I assume it'll need assembler optimizations that gcc can't provide to be really real-time).

 

The gcc compiler does reasonable optimization, I've been pretty satisfied and occasionally impressed with the code it generates on the TI. I've been thinking about that too, so I'd love to see someone try it!

 

[+adamantyr]

If you limited yourself to the cardinal/diagonal directions, it's possible to write a pretty fast 3D engine... although limiting yourself to a maze/block type structure would probably be optimal. To get that true "first person shooter" experience you'd need it to be able to respond fairly fast, which means keeping calculations to a minimum.

 

Myself, I'm biased towards writing it in assembly language.

 

I remember reading somewhere that a guy claimed he could have written Doom on the Atari 800 machine, albeit in low-resolution...

 

Adamantyr

[insomnia]

Using assembly language is probably the way to go here. The GCC compiler would be handy to write the non-critical code more quickly.

 

A few months back I looked into writing a Wolfenstein-style raycaster. I did a quick mockup and made an estimate of the work required, and it seemed pretty do-able. Unfortunately, I never found the time to actually do anything on this.

 

There would be severe limitations on the graphics due to the VDP capabilities, but I don't see any reason why this couldn't be done.

[TheMole]

This is the Apple II example I was speaking of, this is a 40x40 rendering plane so the TI should be able to show something slightly higher res in multicolor:

http://www.youtube.com/watch?v=QUN5CSWiLaw

 

NES:

http://www.youtube.com/watch?v=tPlZI1OTSvY

 

ZX Spectrum (I like the music in this one):

http://www.youtube.com/watch?v=3v7cFGneuaw

 

And of course the c64:

http://www.youtube.com/watch?v=X3Oqz5WjDPI

Edited April 13, 2013 by TheMole

[RXB]

ZX Spectrum has cool music.

[+adamantyr]

Impressive!

[Opry99er]

Wow... It is, indeed, impressive. =)

 

I bet that's possible on the TI by a talented and dedicated programmer. =)

[eshu]

[sometimes99er]

Maybe as complex as it can get would be just 3D blocks, or a hallway/Tunnel Of Doom type view, or maybe something like Atari Battlezone with very simple wire frame graphics.

 

Been playing around with a few 3D effect ideas. Also been playing quite a few RPG’s in my time, but never felt the desire to fire up Tunnels of Doom (based on screenshots). Was interested in the 3D effect (flow and speed) without going to have to try and learn the game. Found this rather nice review which gave me both an insight and examples of the 3D effect in motion without any hassle.

 

 

http://www.youtube.com/watch?v=1LlUCZs1KZA

[Opry99er]

Yea, that is a very good ToD demonstration... There have been some excellent ToD games made, one of my favorites being "The Halls of Moria". This one's the classic Quest of the King, and it is definitely epic.

 

Over the course of my life I've probably spent 70-80 hours down in the dungeons of Kevin Kenney and Hank Mishkoff. Some of the best times of my gaming life were being a kid in my basement hoping my parents weren't awake... Creeping through the Tunnels of Doom and trying to be quiet so I didn't get the "belt" if dad woke up and caught me out of bed.

 

=)

 

Crazy how "ahead of its time" this game was. The 3d/2d rendering concepts were very much unique at the time. ToD opened the way for the Ultima games and had a great influence on the early Elder Scrolls offerings.

[TheMole]

Super cool Atari 8-bit Wolf 3D video

My god, that is definitely the coolest of the bunch. Been trying to read up on how this is done, but don't understand much of the Atari graphics architecture. So this is a scanline interrupt trick flipping between two video modes to give the impression of roughly 256 colors with a 64x64 resolution, right? That is extremely well done, and shows that color depth is probably more important than resolution if you want to do texturing, which I had not expected.

[+adamantyr]

My god, that is definitely the coolest of the bunch. Been trying to read up on how this is done, but don't understand much of the Atari graphics architecture. So this is a scanline interrupt trick flipping between two video modes to give the impression of roughly 256 colors with a 64x64 resolution, right? That is extremely well done, and shows that color depth is probably more important than resolution if you want to do texturing, which I had not expected.

 

I can well believe that... and the Atari 8-bit systems had a very strong advantage in that area, because they actually had a 128 color palette available. Technically you could only have so many on the screen at at time, but by tricking out the scanlines you could make different colors appear on different horizontal lines.

 

When doing graphics for my CRPG on the TI, I have definitely regretted not having more colors available... 15 is just not enough sometimes. (And it irks me that I'm short one color because one HAS to be transparent... oh well.)

 

Adamantyr

[eshu]

My god, that is definitely the coolest of the bunch. Been trying to read up on how this is done, but don't understand much of the Atari graphics architecture. So this is a scanline interrupt trick flipping between two video modes to give the impression of roughly 256 colors with a 64x64 resolution, right? That is extremely well done, and shows that color depth is probably more important than resolution if you want to do texturing, which I had not expected.

 

I might not fully understand myself, I've not done much code on the atari 8-bit and not for a long time. I think it's to do with the way PAL blends luma and chrominance over two scanlines. So they jump between having a palette of 16 colours on one scanline to 16 shades on the other.

 

I would guess you could do something similar to the c64 on a PAL TI - http://www.larshaugseth.com/c64/colmix.html - but I guess your all mostly US based? theres always artifacting........

[+mizapf]

One particular problem that we have with our TI architecture is that the video RAM is only accessible with load / store operations on a byte basis. We are desperately lacking logical operations, moves, calculations. The C64 mapped the video RAM into the main memory so the CPU had direct access. Of course, they were also playing a lot with the scan line interrupt.

 

I believe that we could have achieved much more with the 9938. It has built-in screen operations, and this is what I already used in my Fractals program, for instance, when pulling open a zoom window. Also, I once wrote a program with background music and a candle with a flickering flame. I implemented this as a set of eight images of the flame which I put into the non-displayed area and did a move of the rectangle around the flame to the top of the candle. Also, with the 9938 commands we have move operations so we could pretty easily create soft-scrolling displays. I think I'll do some benchmarks to find out more about the processing speed so we can estimate the change rate depending on the size of the area.

 

None of that is possible with the TI-99/4A VDP. What you can do (I think this has been mentioned) is to pre-draw screens and to exchange different screens using the video registers. For instance, in the Graphics 1 mode we could point to different pattern descriptor tables. However, the register only allows for setting the PDT at >0800 multiples, so this gives us at most 8 such tables. Another chance would be to swap the screen image table and to fill the PDT with shifted patterns. But this is again only possible at >0400 multiples, hence 16 variants. In bitmap mode one could maybe create some nice effects with a clever definition of the screen image.

 

As soon as you need to replace the screens from the CPU memory you have to to a costly transfer from the CPU RAM. Before saying that this is a showstopper, however, one should calculate or measure the actual data rate that we can achieve at most, so maybe this suffices for some applications.

 

Sorry for being pessimistic, but - to sound a bit more positive - this will be a real challenge. I just don't believe the game authors of other computer platforms were much more adept than ours, but we know it ended up in a bunch of ... well ... not-so-attractive games. With some notable exceptions, certainly.

Edited April 16, 2013 by mizapf

[TheMole]

One particular problem that we have with our TI architecture is that the video RAM is only accessible with load / store operations on a byte basis. We are desperately lacking logical operations, moves, calculations. The C64 mapped the video RAM into the main memory so the CPU had direct access. Of course, they were also playing a lot with the scan line interrupt.

 

I believe that we could have achieved much more with the 9938. It has built-in screen operations, and this is what I already used in my Fractals program, for instance, when pulling open a zoom window. Also, I once wrote a program with background music and a candle with a flickering flame. I implemented this as a set of eight images of the flame which I put into the non-displayed area and did a move of the rectangle around the flame to the top of the candle. Also, with the 9938 commands we have move operations so we could pretty easily create soft-scrolling displays. I think I'll do some benchmarks to find out more about the processing speed so we can estimate the change rate depending on the size of the area.

 

None of that is possible with the TI-99/4A VDP. What you can do (I think this has been mentioned) is to pre-draw screens and to exchange different screens using the video registers. For instance, in the Graphics 1 mode we could point to different pattern descriptor tables. However, the register only allows for setting the PDT at >0800 multiples, so this gives us at most 8 such tables. Another chance would be to swap the screen image table and to fill the PDT with shifted patterns. But this is again only possible at >0400 multiples, hence 16 variants. In bitmap mode one could maybe create some nice effects with a clever definition of the screen image.

 

As soon as you need to replace the screens from the CPU memory you have to to a costly transfer from the CPU RAM. Before saying that this is a showstopper, however, one should calculate or measure the actual data rate that we can achieve at most, so maybe this suffices for some applications.

 

Sorry for being pessimistic, but - to sound a bit more positive - this will be a real challenge. I just don't believe the game authors of other computer platforms were much more adept than ours, but we know it ended up in a bunch of ... well ... not-so-attractive games. With some notable exceptions, certainly.

 

Well, I'm not sure I agree (but then I haven't really pushed the limits of the system yet, having only recently restarted coding for the TI). Yes, the lack of bulk moves or memory mapped access to video memory is a big downside. But on the other hand, VDP commands such as block move/copy within video memory will not help you build a 3D ray caster like this. Looking at the MSX1 scene for instance, it's clear that the 9918a alone cannot be blamed for the lack of quality games for the system.

 

So, I have one question, does anyone know how much bandwidth we have from CPU to VDP RAM? In multicolor a full screen refresh would requires us to push 2976 bytes per frame (64*48 / 2), a frame rate of 15 fps or so would require roughly 45kbps. The biggest challenge will be to pull off the calculations of the "slices", the actual ray casting.

 

Note that for this type of algorithm copying within video memory would not help us at all, as we're refreshing the full screen all the time based on real time calculations, so very unpredictable).

[RXB]

Well, I'm not sure I agree (but then I haven't really pushed the limits of the system yet, having only recently restarted coding for the TI). Yes, the lack of bulk moves or memory mapped access to video memory is a big downside. But on the other hand, VDP commands such as block move/copy within video memory will not help you build a 3D ray caster like this. Looking at the MSX1 scene for instance, it's clear that the 9918a alone cannot be blamed for the lack of quality games for the system.

 

So, I have one question, does anyone know how much bandwidth we have from CPU to VDP RAM? In multicolor a full screen refresh would requires us to push 2976 bytes per frame (64*48 / 2), a frame rate of 15 fps or so would require roughly 45kbps. The biggest challenge will be to pull off the calculations of the "slices", the actual ray casting.

 

Note that for this type of algorithm copying within video memory would not help us at all, as we're refreshing the full screen all the time based on real time calculations, so very unpredictable).

 

Mizapf is right. I had the TIM card and that used the 9958 and really made the 16K VDP 9918a look like junk. Massive VDP moves directly to or from RAM (Not 1 byte each time) and Bit Mapped 4 times larger.

More colors, and built in features on chip that would make gaming very cool. The chip 9938 and 9958 was designed for gaming while the 9918a never really was designed for anything but a stop gap version.

[+Vorticon]

Been playing around with a few 3D effect ideas. Also been playing quite a few RPG’s in my time, but never felt the desire to fire up Tunnels of Doom (based on screenshots). Was interested in the 3D effect (flow and speed) without going to have to try and learn the game. Found this rather nice review which gave me both an insight and examples of the 3D effect in motion without any hassle.

 

 

The author of the review, Matt Barton, has written a great book on computer RPG's called Dungeons and Desktops. Highly recommended and incredibly comprehensive archive well worth reading.

[sometimes99er]

We could try and mimic the Atari solution/resolution.

 

With bitmap mode we can have any color assigned horizontally if the "pixels" are 4 pixels wide. First 4 pixels having the background color and the next 4 having the foreground color. The character patterns could all be "0F0F0F0F0F0F". Horizontal "resolution" will be 256 pixels / 4 = 64.

 

It would be nice with the same vertical "resolution" of 64. Also only using every other scanline. We therefore need 128 scanlines, or 128 / 8 pixels = 16 characters = two third of the screen. Very convenient since lower third can then have its own character-set (256 characters).

 

The color area to be updated is 2K. The continuous area is however 4K.

 

This demo pulls 2K from the console ROM.

 

http://www.youtube.com/watch?v=Iy9qdFHknjY

[Tursi]

We've covered the video bandwidth in depth a couple of times, on the stock TI-99/4A (with memory expansion), you can send +/- 2k per frame. The performance of your copy loop has the biggest impact. With unrolling and sticking the loop in scratchpad, on a real machine I was approaching your 2900 bytes per frame number, IIRC.

 

My original research was posted at 99er.net, which I can't get to right now for some reason, but I did find my own comment saying this: At the end of my experimentation, I managed to push 3600 bytes per video frame to the VDP (this does not mean the VDP accepted it, only what the CPU was doing).

 

That would have been a loop in scratchpad using MOVB *R1,*R2 -- note without an increment on the source address (and the destination register points to the video data address). So the real-world copy case will be slightly slower. But here, when I say "per frame", that's per 60hz VDP frame. To push a multicolor display at 15fps is very doable -- you might even be able to double-buffer it (so the redraw isn't visible).

[+mizapf]

I guess there won't be much time left to do anything else but screen updates .

 

Actually, I did not even think about the multicolor mode ... could it be we finally find some reasonable use for this strange mode?

[sometimes99er]

Multicolor mode would probably lean toward the C64 example, which doesn't look quite as enjoyable and playable as the Atari and Spectrum versions. Frames-per-second is of course an issue, since a real slow pace would maybe look pretty but destroy gameplay - to some.

 

Maybe using the Atari style approach, resolution of 64x64, but then "only" doing wire frame graphics (suggested in the first post), would probably be faster than ordinary bitmap line drawing since there are fewer "pixels", at least for a comparable sized bitmap, only color map to update, and no care for or artifacts from color restrictions (we'll have 15 out of 15 and not 2 out of 15 per something). And then of course not forgetting sprites (kept in the same background style) to spice up/speed up some 3D effects, bullets, knobs etc. plus explosions which do not really have to be 3D to work.

 

Edited April 17, 2013 by sometimes99er