First person shooter on the TI? :)

[TheMole]

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

 

That could be nicer looking than multicolor indeed, especially since in this type of engine vertical resolution is typically more important (as long as you don't allow rotation along the view axis) and the thinner pixels + scanlines make it look much more high res. Any idea how much frames per second you're getting in that demo? The bandwidth requirement is roughly the same and has the added advantage of not needing to switch graphics modes mid-scan if you want to display static scoring info and the likes. Everything will look a bit darker though (or brighter if you set the even scanlines to white), but that might not be bad either. Hell, you could use the even scanlines for added effect when you get hit or something (turning them red).

 

Any chance you can redo this video with TV emulation turned on in Classic99?

 

Tursi, for double buffering, why would that need more cycles? Would you not just alternate the pattern/color table locations between frames and change the registers at the next VBLANK interrupt after drawing one full frame?

Edited April 17, 2013 by TheMole

[sometimes99er]

Hell, you could use the even scanlines for added effect when you get hit or something (turning them red).

 

Having the even scanlines (or parts of them) in the transparent color would make for easy color effects.

 

Any chance you can redo this video with TV emulation turned on in Classic99?

 

Cartridge binary attached. Try it out (I will too – too busy to make a video right now).

 

 

 

 

Classic99, Cartridge, User, Open ...

Edited April 17, 2013 by sometimes99er

[sometimes99er]

Any idea how much frames per second you're getting in that demo?

 

An update, as is, apparently takes more than one frame (used custom wait for frame interrupt (not ISR)), so a steady 30 fps (emulation though). It has 8 bytes write rolled out, with 4 of the bytes coming from console ROM (16 bit access) (the other 4 bytes are just blanks for utilizing the VDP pipeline (autoincrement)). Workspace is of course in Scratch PAD, but code is in Cartridge ROM (slower 8 bit access AFAIR).

Edited April 17, 2013 by sometimes99er

[Tursi]

Sometimes99er - finally saw your video demo, agreed, that does have strong potential to look much better than multicolor -- without being much more expensive to calculate. Great idea!

 

Tursi, for double buffering, why would that need more cycles? Would you not just alternate the pattern/color table locations between frames and change the registers at the next VBLANK interrupt after drawing one full frame?

 

It doesn't... when I wrote my statement I was actually thinking about memory. We can't double-buffer the bitmap screen because there isn't enough video RAM, but multicolor with a pattern table -- that would fit in memory twice.

 

I think we need to develop Sometimes99er's idea, though, and see how that looks! The demonstration looks great, but emulators don't handle refresh tearing yet (Classic99 draws the screen all at once, and last time I looked, so did MESS). If it can truly get 30fps and HW (and why not!), then tearing is not likely to be a big deal, we might even be lucky enough to have the refresh happen far enough down the screen so that you can't see it.

[RXB]

What are the chances of 9938 or 9958 VDP as those have enough memory and tons of programs that can run today already written.

Like Y.A.P.P. or Funnelweb or Telco or XHI 80 Assembly support or some others.

I always wanted to update RXB to 80 columns or update to 256 colors and 4 times the bit map size that can actually do a better refresh rate.

[sometimes99er]

What are the chances of 9938 or 9958 VDP as those have enough memory and tons of programs that can run today already written.

Like Y.A.P.P. or Funnelweb or Telco or XHI 80 Assembly support or some others.

I always wanted to update RXB to 80 columns or update to 256 colors and 4 times the bit map size that can actually do a better refresh rate.

 

Why not use the F18A ?

 

I ponder on how 80 columns or 256 colors and 4 times the bit map size, would make RXB support a First Person Shooter.

 

 

EDIT: Ahhh, RXB support for the GPU !!!

 

Edited April 19, 2013 by sometimes99er

[sometimes99er]

Took a famous 32 color image, cropped, resized etc. to get 256 x 128 pixels.

 

 

To me the 9918A has rather bright colors with black as the only exception, so I stretched colors. More than just for kicks, here's an 8K 9918A bitmap version. We get a feel for quality compared with size (8K).

 

 

Took the original (the top one in this post) and reduced the horizontal resolution from 256 to 64 pixels.

 

 

Converted the palette and eliminated every odd scanline. It's now a 2K thing. Less hassle for the CPU (compared with 8K). Maybe not the best image to go demonstrate, but heck, I was able to go through the process.

 

 

Here's the Atari version.

 

 

Here's the 9918A version, with color palette converted manually (just quick and dirty).

 

 

Edited April 19, 2013 by sometimes99er

[TheMole]

Here's the Atari version.

 

 

Here's the 9918A version, which color palette converted manually (otherwise all the brown ones get to be one all dark red etc.).

 

 

 

That's not too bad. That scanline trick really enhances the perceived vertical resolution. Well, actually, it really is increased as well. If we went real mutlicolor we'd have 48 pixels covering the whole screen (or maybe something 36 pixels when doing the same type of widescreen format like on the Atari), this gives us 64 pixels for 2/3 of the screen. So pixel density really goes up.

 

I'm trying to write a simple raycaster (non texturing right now) in C, but converting my floating point to fixed point math is taking much longer than I hoped for . If I want to add the actual rendering step like in your demo, I just initialize the first two name tables with characters 0-256 and the pattern for the first 512 characters to ">0F000F000F000F00". Then each frame, I fill in the color table with >XY where X is the left color, Y the right color for each "double pixel", skipping every other scanline? So something like this:

initialize()
{
 // 0-256 for the first 512 names in the nametable
 for (x=0; x < 512; x++)
   write_to_name_table(x, x % 256);

 // 0f000f000f000f00 for the first 512 patterns in the pattern generator table
 for (x=0; x < 512; x++)
   write_to_pattern_table(x * 8, "0F000F000F000F00");
}

render()
{
 for (x=0; x<64; x += 2)
   for (y=0; y<64; y++)
   {
     two_pixel = raycastbuffer[x, y] << 4 + renderbuffer[x + 1, y];
     write_to_color_table( (x / 2) + (2*y), two_pixel);
   }
}

[+adamantyr]

You COULD write a raster-based engine in multi-color mode... mind you, the mode is absolutely crazy to set up. It's not a linear map, which means your raster engine has to do some math to place points on the screen.

 

The good news is there is space in the VDP for two full-size pattern tables of 1536 bytes, so you can double-buffer things for a smooth transition. (AND room for 2k of sprite patterns too, so you can do all the monsters and effects...) The main question is if you can make the raster engine run fast enough to render at 15 FPS or better.

 

One definite thing to avoid is floating-point math. Specifically the ROM routines in the console; they're way too slow and ponderous for this work. But in general with the small resolution, you just don't NEED that level of accuracy. Trigonomic functions can be done using a look-up table with byte-size or even word-size ratios.

 

Adamantyr

[+adamantyr]

Come to think of it, a starting point for a prototype engine is actually Graphics Mode 1. If you can get it working at 32x24 size, then you can just move it up to Multi-color mode. It's possible to even abstract the engine elements so that all you do is swap out the graphic mode and change a "pixel plot" routine so it maps correctly in Multicolor's bizarre setup.

 

I'm not entirely certain the old TI has the processing power to make a PLAYABLE game, though... I'll need to grab a game book I have on raster engines to research it, but I think you'd have to chop out so much stuff it would end up being fairly simplistic at the end. (Texture mapping in particular would be a headache...)

 

Adamantyr

[sometimes99er]

@TheMole, Yep, I think you got the idea. Not sure about the first parameter of write_to_color_table. How about simply supplying x and y as separate parameters, and leave the calculation of correct target address to the method. The bitmap layout is one character down then the next. So you go 8 bytes down, then moving right (and up if you move like a pen) to the start of next character. Of course when a row is finished (32 characters) it's down and all to the left to the beginning of the next line.

 

Here's the C64 version (presented earlier). Resolution is 40x50 pixels.

 

 

Here's a quick and dirty 9918A multicolor version. Resolution is 64x48 pixels.

 

 

Edited April 19, 2013 by sometimes99er

[+adamantyr]

@TheMole, Yep, I think you got the idea. Not sure about the first parameter of write_to_color_table. How about simply supplying x and y as separate parameters, and leave the calculation of correct target address to the method. The bitmap layout is one character down then the next. So you go 8 bytes down, then moving right (and up if you move like a pen) to the start of next character. Of course when a row is finished (32 characters) it's down and all to the left to the beginning of the next line.

 

Here's the C64 version (presented earlier). Resolution is 40x50 pixels.

 

 

Here's a quick and dirty 9918A multicolor version. Resolution is 64x48 pixels.

 

 

 

Nice! When you say "quick and dirty", you mean you just did up a drawing in multicolor, right?

 

I'm curious if the C64 one actually had a full ray-casting engine behind it.

 

Adamantyr

[sometimes99er]

Come to think of it, a starting point for a prototype engine is actually Graphics Mode 1.

 

That’s another great idea. At first each character can be any of 15 colors, but still very “low” resolution at 32x24 pixels. The number (or amount) of colors per character could be extended with a bit of dithering, like maybe reusing 8 character definitions throughout all of 256 characters to get effects like this. Inner subpixels, like 1 to 4 pixels in a character with maybe black framing for a non-multicolor effect and of course always only 1 color with each character, might work though. When the calculations are done, the 768 or maybe just 512 byte transfer is perhaps not so much of a bottleneck.

 

 

[sometimes99er]

When you say "quick and dirty", you mean you just did up a drawing in multicolor, right?

 

Yep.

[RXB]

Why not use the F18A ?

 

I ponder on how 80 columns or 256 colors and 4 times the bit map size, would make RXB support a First Person Shooter.

 

 

EDIT: Ahhh, RXB support for the GPU !!!

 

 

The F18A will not run Funnelweb or any of the programs like XHI or YAPP.

And as far as I know it does not have 256 colors or more memory does it?

[matthew180]

No, the F18A does not provide any VRAM over the original 16K other than the extra 2K available to the GPU. Adding the extra external VRAM would have increased everything (cost, board size, component count, complexity, etc) and the goal of the F18A was a 9918A replacement to drive a VGA monitor, not a 9935/58 replacement.

 

As for colors, the F18A has 64 programmable color registers that are 12-bit each, i.e. you can select from a palette of 4096 colors. GM1 has been expanded to support up to 2, 4, or 8 colors per tile instead of the normal 2-color foreground/background.

 

However, the F18A does provide a true pixel addressable bitmap *layer* (available no matter the "mode") that would be ideal for this kind of thing. The BML (bitmap layer) is limited to 4 colors (2 bits per pixel), but the width/height of the BML can be specified and only the necessary amount of VRAM will be used. So you could have a 128x128 window, for example, that uses about 6K of VRAM, or go full screen and use about the same amount of VRAM as GM2. The GPU also has a custom "plot pixel" instruction that can set a BML pixel from and X,Y coordinate in a single instruction (meaning it is very fast).

 

[TheMole]

However, the F18A does provide a true pixel addressable bitmap *layer* (available no matter the "mode") that would be ideal for this kind of thing. The BML (bitmap layer) is limited to 4 colors (2 bits per pixel), but the width/height of the BML can be specified and only the necessary amount of VRAM will be used. So you could have a 128x128 window, for example, that uses about 6K of VRAM, or go full screen and use about the same amount of VRAM as GM2. The GPU also has a custom "plot pixel" instruction that can set a BML pixel from and X,Y coordinate in a single instruction (meaning it is very fast).

 

Problem is that there will never be enough bandwidth to push that many pixels to the F18A every frame, even a 128x128 layer is already 3 times as expensive to push as the 64x64 solution sometimes99er came up with. However, if the actual ray casting algorithm could be run on the GPU the story might be different. Should be doable in 2K, and the GPU should be plenty fast enough to do so. Issue there might be that you will have to store the textures in VRAM for that to work if you want to do it texture mapped. 2bpp 32x32 textures would require 256 bytes each, and you'd need 8k for a 256*128 bitmap layer (same screen area as in the "pure" TI version we've been discussing). Double buffering would be out of the question, but it could very well work!

 

But let's get the basic version up and running first... that'll be quite the challenge to begin with .

Edited April 20, 2013 by TheMole

[TheMole]

I'm curious if the C64 one actually had a full ray-casting engine behind it.

 

I'd be surprised if it didn't. I would not know how to do this any other way and a basic ray caster is only a couple of hundred lines of C code anyway...

[matthew180]

The GPU can access and execute code from any part of the 16K VRAM, in addition to the private 2K. It is not limited to just the private 2K. So the code / data address space for the GPU is from >0000 to >47FF.

 

Since the BML is limited to 4 colors, procedural textures might be better than bitmap textures in some cases.

 

I don't think double-buffering would be necessary if the GPU is running the raycasting. I don't know though, I have not had time to really work with the F18A for fun. Since with raycasting you don't have to worry about cleaning the view, I think the window could be updated at 30 or 60 FPS. It would be interesting to find out though.

 

[+InsaneMultitasker]

I was searching for a method to use the V9938 scroll register to implement vertical scrolling. Though my search didn't turn up anything to help me, I did run across this article that may be of interest for FPS coding...

 

http://msx.gnu-linux.net/doomlike/doomlike.html

[+adamantyr]

I was searching for a method to use the V9938 scroll register to implement vertical scrolling. Though my search didn't turn up anything to help me, I did run across this article that may be of interest for FPS coding...

 

http://msx.gnu-linux...e/doomlike.html

 

That is a great site! It explains a lot of the issues and potential solutions for writing an FPS on a vintage machine.

 

I was considing the 8-bit/16-bit coordinate system it mentions... the TI has a distinct advantage here that the word size is natively 16-bits. So it's actually tighter in code to just stick with words instead of bytes. The pain is that your coordinate system takes up twice the footprint...

 

Adamantyr

[+InsaneMultitasker]

That is a great site! It explains a lot of the issues and potential solutions for writing an FPS on a vintage machine.

 

I was considing the 8-bit/16-bit coordinate system it mentions... the TI has a distinct advantage here that the word size is natively 16-bits. So it's actually tighter in code to just stick with words instead of bytes. The pain is that your coordinate system takes up twice the footprint...

 

Adamantyr

 

I just now realized I forgot to include the parent site! The article section has some goodies, including the above Doomlike article!

 

http://map.grauw.nl/

 

I came across the site in part to read the "23-steps to high resolution on MSX1" series but I can only find the first two articles. I do not know if the remaining 21 were ever written but the first two were quite fascinating!

 

http://www.mccw.hetlab.tk/91/msx1demos1/en.html

[Bones-69]

Wow - You guys really run with stuff quickly around here! If this ever eventuates it would be quite remarkable, considering Wolf/Doom came out more than a decade after the TI!

[Willsy]

One definite thing to avoid is floating-point math.

 

Indeed. Shouldn't need FP at all for such a small resolution.

[Willsy]

I was searching for a method to use the V9938 scroll register to implement vertical scrolling. Though my search didn't turn up anything to help me, I did run across this article that may be of interest for FPS coding...

 

http://msx.gnu-linux...e/doomlike.html

 

Probably the same technique as the C64: You update the scroll register once each frame, (increment it or decrement it) which moves the screen up/down by one pixel. On the 8th frame, rather you reset the scroll register to 0, and do a 'character level' scroll. If the character scroll is done at the right time, you don't see it, as it's done as the raster is on the flyback.

 

This was very simple on the C64, because the video memory was part of the CPU memory. Not so simple on our box with access via an I/O port. :-(

 

So, probably best to keep the video frame in CPU ram, then write it to VRAM as quick as possible (no real problem). Now, you can be working on your character level scrolling in CPU RAM while doing other stuff (like updating the scroll register, reading joysticks, updating sprites etc). Then, when it's time to reset the scroll register, your next frame has been scrolled in CPU RAM and you just blast it out to VRAM.