Jump to content

Recommended Posts

Posted (edited)
5 hours ago, Vorticon said:

Does this require the F18A?

No it doesn't. It even runs on MAME 🙂.

Edited by Asmusr
  • Like 1
  • Thanks 1

Share this post


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

No it doesn't. It even runs on MAME 🙂.

Mind blowing... I so wish we had that back in 1981!

  • Like 1

Share this post


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

Now you could add doors that slide up or down

I think sideways would be a lot easier.

Share this post


Link to post
Share on other sites
Posted (edited)
7 hours ago, Asmusr said:

I think sideways would be a lot easier.

If you move it by a column at time it would fit into the ray casting algorithm and you can make it slide with the horizontal resolution of one character

The tricky part is if you have to put them into the middle of a map cell,thinner than a wall

Edited by artrag
  • Like 1

Share this post


Link to post
Share on other sites

This video is made on a PC, but it's showing graphics that the TI-99/4A would be capable of if it was fast enough. It's using the 4x1 fat pixel bitmap mode of the 9918A that you get by setting the pattern table to a fixed 11110000 pattern and only updating the color table. I'm pretty sure it wouldn't be fast enough on a TI for a first person shooter, but for a dungeon crawler game it might be fine. 

 

 

  • Like 8

Share this post


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

This video is made on a PC, but it's showing graphics that the TI-99/4A would be capable of if it was fast enough. It's using the 4x1 fat pixel bitmap mode of the 9918A that you get by setting the pattern table to a fixed 11110000 pattern and only updating the color table. I'm pretty sure it wouldn't be fast enough on a TI for a first person shooter, but for a dungeon crawler game it might be fine. 

 

 

Is this Multicolor mode?

Share this post


Link to post
Share on other sites

It would need 64 rays instead of the current 32 in the algorithm for rendering.  Apart the cpu time for the raycasting, the problem would be the transfer a full frame of 6KB corresponding to the 64x192 fat pixels 4x1 (on MSX1 transferring to VRAM 6KB of linear data takes about 3 VDP frames). 

 

A possibility to reduce the VRAM transfer could be to update only the part of columns that actually changes. This works well on walls with flat colors.

The idea is that when you get closer to walls, you need to add few colored pixels on the top and on the bottom of each the column. So the I/O load is about two bytes per column.

When you get farther from walls, on each column you need to replace few pixels on the top and on the bottom of the column by sky/floor colors. Even in this case the I/O load is about two bytes per column.

When you rotate the view, all columns change of few bytes, except the columns that are those close to the edges of the walls, that need to be integrally updated with a new color. The I/O load can vary, but it is by far lower than 6KB.

A simple data structure to achieve this result is to store in RAM an array with the 64 heights of the walls in the current scene and another with the corresponding colors. The ray caster will tell you the new height and color of each column. 

If colors are equal, if the new height is larger than previous, you add only few wall pixels on top and bottom of the column, otherwise you remove wall pixels on top and bottom of the column and plot ceiling/floor pixels.

If colors are different, if the new height is larger, you plot the whole column by the new color, if the column is shorter, you plot also ceiling/floor pixels.

 

It can be expanded with walls where the textures are horizontal stripes, at cost of storing multiple couples of arrays, one for the height of the color band within the wall another with its color.

 

 

 

 

 

Share this post


Link to post
Share on other sites
12 hours ago, artrag said:

It would need 64 rays instead of the current 32 in the algorithm for rendering.  Apart the cpu time for the raycasting, the problem would be the transfer a full frame of 6KB corresponding to the 64x192 fat pixels 4x1 (on MSX1 transferring to VRAM 6KB of linear data takes about 3 VDP frames).

If you drop the lower third from the screen, like in my raycaster or the megademo, you only need to transfer 4k. I believe we once came to the conclusion that we have a bandwidth of slightly more than 2k per frame on the TI. That would imply 2 frames to update the entire screen.

 

As far as number of rays to cast goes, I've been wondering if there's a way to interpolate the calculations... Could you just calculate 32 rays (e.g. only the odd ones) and fill in the gaps by averaging the height of the two columns next to it? Sure, you'd need to have a special case for when the ray hits a new wall, but perhaps it wouldn't be too awful looking if you just copy the height of the previous column in that case...

 

Either way, this proves that horizontal resolution is much more important than vertical resolution!

  • Like 2

Share this post


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

This video is made on a PC, but it's showing graphics that the TI-99/4A would be capable of if it was fast enough. It's using the 4x1 fat pixel bitmap mode of the 9918A that you get by setting the pattern table to a fixed 11110000 pattern and only updating the color table. I'm pretty sure it wouldn't be fast enough on a TI for a first person shooter, but for a dungeon crawler game it might be fine. 

 

 

Not sure if this is correct though. Even looking at the thumbnail of the video, your horizontal resolution seems higher than what the 9918a can display using the 4x1 macropixel method. Look at the slope of the leftmost block. That looks like it uses a 1x1 pixel resolution to me. I think you've only applied the 4x1 limitation to the textures themselves.

Share this post


Link to post
Share on other sites
5 hours ago, TheMole said:

If you drop the lower third from the screen, like in my raycaster or the megademo, you only need to transfer 4k. I believe we once came to the conclusion that we have a bandwidth of slightly more than 2k per frame on the TI. That would imply 2 frames to update the entire screen.

 

As far as number of rays to cast goes, I've been wondering if there's a way to interpolate the calculations... Could you just calculate 32 rays (e.g. only the odd ones) and fill in the gaps by averaging the height of the two columns next to it? Sure, you'd need to have a special case for when the ray hits a new wall, but perhaps it wouldn't be too awful looking if you just copy the height of the previous column in that case...

 

Either way, this proves that horizontal resolution is much more important than vertical resolution!

Thanks for sharing your thoughts, interesting discussion here. When you say that the bandwidth is around 2k per frame on the TI, what is the frame rate you're assuming? Probably not 60fps, more like 30fps?

  • Like 1

Share this post


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

Not sure if this is correct though. Even looking at the thumbnail of the video, your horizontal resolution seems higher than what the 9918a can display using the 4x1 macropixel method. Look at the slope of the leftmost block. That looks like it uses a 1x1 pixel resolution to me. I think you've only applied the 4x1 limitation to the textures themselves.

This version has a superimposed 8x8 grid. Where do you see that slope?

 

grid8x8.thumb.png.9e7f96e187e938a23c5653bb4e030139.png

  • Like 1

Share this post


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

Thanks for sharing your thoughts, interesting discussion here. When you say that the bandwidth is around 2k per frame on the TI, what is the frame rate you're assuming? Probably not 60fps, more like 30fps?

That's for 60fps. But 2k is if almost all your instructions are movb to the vdp, which is difficult to achieve in practice.

  • Like 1

Share this post


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

Thanks for sharing your thoughts, interesting discussion here. When you say that the bandwidth is around 2k per frame on the TI, what is the frame rate you're assuming? Probably not 60fps, more like 30fps?

60fps, or 16.7ms per frame.  One byte can be written in 24 cycles by setting to the workspace pointer to the VDP write data address, then use a chain of "LI R0,>XX00" for each byte.  The LI instruction is 4 bytes, so the code size will be 4 times the number of bytes written, and would need to be running out of expansion or cartridge RAM.  So 2048 * 24 cycles / 3MHz results in duration of 16.4ms.  You would need something like the strangecart to do the raycasting and color table generation on the ARM processor, then expose it as LI R0 instructions to the cartridge space, which the 9900 would then blast to the VDP.

  • Like 3

Share this post


Link to post
Share on other sites
13 hours ago, PeteE said:

60fps, or 16.7ms per frame.  One byte can be written in 24 cycles by setting to the workspace pointer to the VDP write data address, then use a chain of "LI R0,>XX00" for each byte.  The LI instruction is 4 bytes, so the code size will be 4 times the number of bytes written, and would need to be running out of expansion or cartridge RAM.  So 2048 * 24 cycles / 3MHz results in duration of 16.4ms.  You would need something like the strangecart to do the raycasting and color table generation on the ARM processor, then expose it as LI R0 instructions to the cartridge space, which the 9900 would then blast to the VDP.

That is in fact what I was thinking of doing, i.e. just have along stream of LI R0 instructions (and perhaps occasional LI R1 to update VDP pointer) in cartridge memory. This way you would have sections of the TMS9918 VDP memory exposed to the ARM processor, so that every 4th byte would be VDP memory byte and the rest code. I was thinking that at the end of each long stretch of LI R0 instructions there would a branch to the beginning, and that branch instruction fetch could cause the ARM side to switch to another "ROM" bank. That would a simple way to synchronise the ARM and TMS9900. While the TMS9900 is running through one stretch, the ARM would generate the next.

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)
18 hours ago, Asmusr said:

This version has a superimposed 8x8 grid. Where do you see that slope?

 

grid8x8.thumb.png.9e7f96e187e938a23c5653bb4e030139.png

You're right, I was looking at it on my phone and the resolution seemed implausibly high, but this indeed fully fits within the capabilities of the VDP

Edited by TheMole
type-o

Share this post


Link to post
Share on other sites

Thanks for the comments and suggestions. Just to explain, for a fast raycaster I think I'm well covered by the one I already made. If I decide to make another, texture mapped one, I'm well aware that it wouldn't run fast enough for an action game, but for a turn based RPG game it could be fine. See this video where I have set the speed to 2 FPS. It's moving 1 block at a time and turning 90 degress. I think that would be doable on the TI. I'm a big fan of RPGs like Might and Magic III.

 

 

  • Like 1

Share this post


Link to post
Share on other sites

Even a single level first person shooter that even remotely resembled Wolfenstein 3D would be killer in my book.  So what if there may be a little chop here or there, so what if the resolution is not "PC-grade", so what if the screen image may be smaller, so what, so what, so what?  Perfection is for the Borg, for everyone else it's the enjoyment of the game. 

  • Like 1

Share this post


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

Perfection is for the Borg

Is that the Omega directive?

 

  • Like 2
  • Haha 2

Share this post


Link to post
Share on other sites
29 minutes ago, Asmusr said:

Is that the Omega directive?

 

 

HA!  I remember that Voyager episode!

775262865_Directive.thumb.jpg.7ab4ff30acf82b482e6421e6557c061e.jpg

 

Share this post


Link to post
Share on other sites
Posted (edited)

I have turned it into a playable, one level demo. I have added a health bar, a score, and a sound player.

 

 

The guards can now shoot you. You can no longer shoot the walls in general, but you need to shoot the doors to open them. I use that event to spawn new guards and chests.

You complete the level by finding the multi-colored wall, and you die if you run out of health. In both cases the level simply restarts.

raycaster.dsk raycaster.rpk raycaster8.bin

Edited by Asmusr
Added files
  • Like 12
  • Thanks 1

Share this post


Link to post
Share on other sites

This is amazing, Rasmus!

 

I was stuck trying to figure out what kind of maze would help my Katamari demo be a game. If I were going to back to

that, instead of just scrolling 2d bitmap, I would like to do something like this.  There would be a lot of sprites for the

things you run over (the object of the game is for Munch Man to roll over all the sprites and get bigger.)

 

Will you be sharing the source when you are done?

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...