Asmusr

I'm not going to make a WW2 related game, so no.

I agree it's probably best not to lose any horizontal resolution, although that would have the biggest effect on performance since fewer rays would have to be cast.

Thanks, that's definitely better than mine. Here's a version using your door. What I'm looking for now is dungeon textures and maybe a few monsters, so I can make a demo in a dungeon setting. texcaster8.bin

This is close to my vision for the textured raycaster, but I don't think it's likely to happen.

In this version I'm not doing all the hard work of updating the screen if you're not moving. That makes it possible to open the doors by shooting them almost like before. texcaster.rpk texcaster8.bin

It looks like you're using the first generation of the emulator, and maybe an old version of that, because the sound issue was fixed in one of the last versions. You have to call a function (AudioContext.resume()) from a handler triggered by the user. That way browsers prevent websites from making sounds without the user's approval. Internet Explorer has never been supported. Couldn't you just use https://js99er.net/#/cart/munchman for the compo?

I have fixed the map issue in this version. It also has more optimizations: unpacked textures and some code moved to scratch pad. I'm not sure the difference is that noticeable, however. texcaster8.bin texcaster.rpk

Here is the latest cartridge file for the textured raycaster if you want to try it. My TI has been packed away since the beginning of Corona, so I haven't actually tried this or the fast raycaster on real hardware. texcaster8.bin

I would be happy to discuss how to implement Minecraft for the TI in another thread. 🙂

Yes I will try. But it actually requires 4 times the space since I need each pixel in both upper and lower nibble for the max efficiency. Since each texture is 16x64 pixels it will take 2K per texture, so I have to move to a larger bank switched cartridge where I can store 4 textures in each 8K bank. The other part of the inner texture loop is calculating the source texture address. I use three 16-bit registers for that: - One for the base address of the texture column. - One for the offset into the column, represented as an 8.8 fixed point number. - One for the increment to the offset for each screen pixel, also FP 8.8. For each pixel written I add the increment to the offset and the high byte of the offset, which is the number of whole pixels, to the column base address. Actually I think that could be done slightly faster as well if I could assume that no texture column crosses a 256 byte boundary.

If you mean like like Minecraft then no - that would require a real 3D engine that supports horizontal surfaces, for instance.

Here is the latest version of the non-textured game. It has a boss at the end and a little puzzle. raycaster.dsk raycaster.rpk raycaster8.bin

It could be a bit faster if I 'unpacked' my textures (from 2 pixels/byte to 2 textures with 1 pixel/byte) so I didn't have to spend time shifting bits around.

You can swap in a 4K SAMS page at >F000 (not >FE00) by setting the SAMS register at >401E to the SAMS page number you want to swap in.

You could also save each page in a separate 'program' file. Then you don't have to deal with records, it will be faster to save and load (I think), and you can easily save only the modified pages.

The textures are drawn in an online tool (Raphael) I made for the purpose, because I couldn't find anything else that would create seamless textures with fat pixels. https://raphael.js99er.net/ It works with .rap files like the attached, which are really just text files in JSON format. brick-texture.rap

I fixed some bugs and optimized a bit, and it now looks like this: The screen in drawn in bitmap mode using the color table only, which gives a resolution of 64x192 with fat 4x1 pixels in full 16 colors.

The code is on GitHub: https://github.com/Rasmus-M/raycaster

I want to do more work on the texture code branch before I share it. The textures are not edited in Magellan but in an editor I wrote for that purpose.

I think we should still maintain the rpk format in the TI community, even in the event that MAME stopped supporting it. And I would very much like to see Classic99 supporting it too.

It looks like UTF-8 encoded characters that are not properly decoded. Maybe I will look at it tomorrow.

I like the rpk format because it's one program one file. In a browser you cannot load a file that the user didn't ask for, so you cannot load digdugd.bin if the user asked for digdugc.bin. One thing I believe the rpk format is missing is the ability to load GROMs at different bases.

Thanks. You're welcome to improve the graphics. I have attached the Magellan file. It also contains the first level map if you want to design another one. map2.mag

I fixed a number of issues, and now it's close to working correctly. But I still think there is some issue with the textures in the horizontal direction. js99er-20200808201555.webm Although the code is not yet optimized, clearly textures are too slow for the a person shooter, so this branch of the code intended for something like an RPG.

After fixing a mask it looks like this. js99er-20200807201725.webm