Is there any "Doom"-like games on the TI?

[xabin]

After seeing Doom being ported on a bunch of stuff (including Notepad), I'm wondering if there's been a Doom port for the TI, or any similar games for the computer, either original or modern homebrew. I know of Tunnels of Doom, but other than that, dunno if anyone's explored this option, yet. Any suggestions would be appreciated.

[jrhodes]

Not exactly, but we do have this:

 

[xabin]

That is actually pretty cool. Wonder if a full game could be made like that...

[pixelpedant]

This is why I included "Corridor Shooter" as one of the options in my thread about underserved genres on the system.  I feel like we're weirdly missing the maze/hallway shooter (or otherwise, maze action game) genre.  Even a primitive MIDI Maze style maze shooter would be cool. 

 

The closest I can think of that we've got is Wizard's Lair/Wizard's Doom.  Which is a maze game involving real time enemy movement and real time combat (a la Dungeons of Daggorath, kind of).  But it's clearly an RPG by design and intent - not an action game. 

[Frozone212]

It was a miracle to get running on the Vic but the TI has different architecture so it would be amusing to see what the 9900 could pull off.

 

Oh TI, if only you had given us more scratchpad ram...

[xabin]

Well, who knows? There's a version of Doom on TI graphic calculators, so I'm sure one can be made for the TI-99/4A.

[Frozone212]

it would have to be in assembly or forth.

BASIC is SLOOOOOW!

[TheMole]

5 hours ago, xabin said:

Well, who knows? There's a version of Doom on TI graphic calculators, so I'm sure one can be made for the TI-99/4A.

Doom? No, not possible. Wolfenstein is already a stretch...

 

For reference: this is the closest to Wolfenstein 3D on a platform with the same VDP (Sega SG-1000) I've seen so far:

 

Uses the same principle (pre-defined characters in the nametable) as my proof-of-concept from a couple of years ago:

 

Rasmus did a very optimized and very impressive textured raycaster ala Wolfenstein a while back, but it made some sacrifices regarding freedom of motion to make it playable at the achievable framerate:

https://www.youtube.com/watch?v=Q19eMT1BGiw

 

Then there is this for the F18A (als Rasmus), which is probably the furthers we can push a ti99/4a if you're okay with requiring an F18A VDP replacement:

 

 

 

[Asmusr]

18 hours ago, xabin said:

There's a version of Doom on TI graphic calculators, so I'm sure one can be made for the TI-99/4A.

Well, the TI-83+ is powered by a 6 MHz Z80 which I believe is quite a lot faster than the 3 MHz TMS9900 in the TI-99/4A. It only needs to update a 96x64 screen as opposed to 256x192, and it probably has direct access to the video memory.

 

However, if we made the window size very small, like on the VIC-20, we could probably get a textured raycaster to run at a reasonable speed on the TI-99/4A, using the same technique I used for my textured raycaster demo game, but with smooth rotation. 

[SkyPilot]

Process everything on the TIPI/RPi and have TI just display graphics?

Edited October 13, 2022 by SkyPilot

[+OLD CS1]

2 hours ago, SkyPilot said:

Process everything on the TIPI/RPi and have TI just display graphics?

I mean, at some point just graft a 9918A or F18A onto a RPi and run an emulator.

[SkyPilot]

2 minutes ago, OLD CS1 said:

I mean, at some point just graft a 9918A or F18A onto a RPi and run an emulator.

So much is already done in new hardware like FinalGROM, F18A and TIPI anyway, so it's nothing new.  I have no issues with a new class of programs.

[TheMole]

Doom on the SNES used the SuperFX chip, so it's not unheard off to use external hardware support for these kinds of things. I do get the appeal of squeezing the most out of the system that was originally released though.

[TheMole]

This C64 ray tracer is impressively fast: 

 

[pixelpedant]

Here's another interesting example of 9918A gameplay involving 3D textured maze environments: Tales of Popolon (MSX1)

 

 

Graphics are bitmap mode, but with 2x2 "pixels".

[+OLD CS1]

10 hours ago, TheMole said:

This C64 ray tracer is impressively fast:

Calculations aside, the Commodore 64 benefits from direct CPU access to video memory, and that the video processor (VIC-II) accesses memory on the opposite clock phase as the CPU.  VIC will "ask" for extra time when needed.  Nonetheless, it has been proven here that it is still possible to shovel a lot of data at the VDP.

[pixelpedant]

The way I look at it, if anyone ever takes this challenge all the way, for the purpose of a full-fledged game, however low resolution you need to go is just how low you need to go.  Might as well accept that and make the best of it.  If that means a screen which is 2/3 interface and 1/3 first-person viewport, so be it. 

 

RPGs (or dungeon crawls in general) with dungeon views occupying a relatively small proportion of the screen (with most of it being interface) are fairly common.  So that might be one better context for such a thing, where it doesn't feel out of place. 

[TheMole]

10 hours ago, OLD CS1 said:

Calculations aside, the Commodore 64 benefits from direct CPU access to video memory, and that the video processor (VIC-II) accesses memory on the opposite clock phase as the CPU.  VIC will "ask" for extra time when needed.  Nonetheless, it has been proven here that it is still possible to shovel a lot of data at the VDP.

True dat, the shared memory benefit other platforms have over VDP is significant, and I do believe the bottleneck in most implementations we've seen on the TI so far are related to CPU-VDP bandwidth constraints.

 

Still, I'd love to take a look at the source code for the C64 example. Apparently, it's entirely written in C, and it seems to be faster than other examples I've seen on any 6502 platform... I'm curious if they've found some other optimizations we haven't thought off related to the actual ray casting algorithm. Looking at stills from the video, it seems like this only runs at a 40-column horizontal resolution, but they're obfuscating the low resolution with the dithering pattern. It also doesn't show the fish-eye effect you see on other 8-bit implementations (like populous above). Rasmus's more feature-rich version runs almost just as fast though, and that has enemy sprites, game logic, etc... that I assume takes up quite some resources as well.

Edited October 20, 2022 by TheMole

[+OLD CS1]

On 10/20/2022 at 2:37 AM, TheMole said:

True dat, the shared memory benefit other platforms have over VDP is significant, and I do believe the bottleneck in most implementations we've seen on the TI so far are related to CPU-VDP bandwidth constraints.

In the case of the Commodore 64 and 128, the shared memory is a benefit, but more so that the VIC-II and the 6510 alternate use of the memory buss.  I suspect that if they had to compete for the buss, the machine would run into a performance bottleneck similar to memory access windows of the VDP.  But, the VIC-II/CPU architecture came at least three years after the VDP.  The dedicate RAM of the VDP means that the CPU can do other things while the VDP fetches what it needs from memory.  Both architectures are solutions for the same problem.

 

EDIT: Also note, on the Commodore 128, the 80-column VDC can address 64k of dedicated RAM (16k standard, 64k on the 128D or with upgrade,) with ported CPU access similar to that of the 9918/A VDP.