Asmusr Posted May 30, 2020 Author Share Posted May 30, 2020 (edited) 5 hours ago, Vorticon said: Does this require the F18A? No it doesn't. It even runs on MAME ?. Edited May 30, 2020 by Asmusr 1 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted May 31, 2020 Share Posted May 31, 2020 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! 1 Quote Link to comment Share on other sites More sharing options...
artrag Posted May 31, 2020 Share Posted May 31, 2020 Now you could add doors that slide up or down Quote Link to comment Share on other sites More sharing options...
Asmusr Posted May 31, 2020 Author Share Posted May 31, 2020 2 hours ago, artrag said: Now you could add doors that slide up or down I think sideways would be a lot easier. Quote Link to comment Share on other sites More sharing options...
artrag Posted May 31, 2020 Share Posted May 31, 2020 (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 May 31, 2020 by artrag 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 3, 2020 Author Share Posted June 3, 2020 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. 8 Quote Link to comment Share on other sites More sharing options...
RXB Posted June 3, 2020 Share Posted June 3, 2020 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? Quote Link to comment Share on other sites More sharing options...
artrag Posted June 3, 2020 Share Posted June 3, 2020 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. Quote Link to comment Share on other sites More sharing options...
TheMole Posted June 4, 2020 Share Posted June 4, 2020 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! 2 Quote Link to comment Share on other sites More sharing options...
TheMole Posted June 4, 2020 Share Posted June 4, 2020 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. Quote Link to comment Share on other sites More sharing options...
speccery Posted June 4, 2020 Share Posted June 4, 2020 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? 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 4, 2020 Author Share Posted June 4, 2020 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? 2 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 4, 2020 Author Share Posted June 4, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
PeteE Posted June 4, 2020 Share Posted June 4, 2020 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. 3 Quote Link to comment Share on other sites More sharing options...
speccery Posted June 5, 2020 Share Posted June 5, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
TheMole Posted June 5, 2020 Share Posted June 5, 2020 (edited) 18 hours ago, Asmusr said: This version has a superimposed 8x8 grid. Where do you see that slope? 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 June 5, 2020 by TheMole type-o Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 5, 2020 Author Share Posted June 5, 2020 (edited) 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. [video deleted by mistake] Edited September 2, 2020 by Asmusr 1 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 5, 2020 Share Posted June 5, 2020 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. 1 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 5, 2020 Author Share Posted June 5, 2020 1 hour ago, Omega-TI said: Perfection is for the Borg Is that the Omega directive? 2 2 Quote Link to comment Share on other sites More sharing options...
Omega-TI Posted June 5, 2020 Share Posted June 5, 2020 29 minutes ago, Asmusr said: Is that the Omega directive? HA! I remember that Voyager episode! Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 5, 2020 Author Share Posted June 5, 2020 (edited) Now with speech and a talking chest. ? raycaster.dsk raycaster.rpk raycaster8.bin The guards, being very polite, recognize that you're one handed. Edited June 6, 2020 by Asmusr 8 Quote Link to comment Share on other sites More sharing options...
Asmusr Posted June 12, 2020 Author Share Posted June 12, 2020 (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 June 12, 2020 by Asmusr Added files 12 1 Quote Link to comment Share on other sites More sharing options...
broettger Posted June 12, 2020 Share Posted June 12, 2020 Impressive! Quote Link to comment Share on other sites More sharing options...
ti99iuc Posted June 12, 2020 Share Posted June 12, 2020 It is great!! thanks Rasmus! Quote Link to comment Share on other sites More sharing options...
+FarmerPotato Posted June 12, 2020 Share Posted June 12, 2020 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? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.