Asmusr

It seems fine to me.

This version has textured ceiling and floor. There are 8 directions, and you're moving 1 square at a time so the textures don't have to move. The whole 6K background with the textures is simply copied from ROM to the screen buffer before drawing the walls, so I was surprised that it's running as fast as this, but the old ceiling/floor drawing must also have taken a lot of time. texcaster8.bin

Would it be possible to add a new cartridge type to the FG99 where you could page in 4K pages of the ROM at >6000 and >7000 independently? So, for instance, you could page in >0000->0fff of the ROM at >6000 and >2000->2fff of the ROM at >7000? Or even the same 4K at both >6000 and >7000?

The Linux emu = TI-99/Sim

It's a good suggestion but it won't work (for the floor at least) if I start adding other objects to the screen buffer. Maybe an object will never overlap the ceiling so there it would work?

9 out of 10 people have replied yes to having "a new subforum for Tomy Tutor, 99/8 and close relatives of the TI-99-4a", so maybe that's what we should do instead of starting a new discussion?

I haven't upgraded to version 3 yet. ;-) The -w option is just to suppress warnings about unused labels.

My plan is to make a textured ceiling, which will perhaps just be a static image.

I think you're looking at the master branch, which contains the non-texture mapped code. You need to look at the texture_mapped_unrolled branch. It's correct that I could use a single column RAM buffer as it is now, but when I start adding objects on top of the background it would be more difficult. The full screen buffer also makes the screen update shorter and possibly less flickering than a single column buffer.

No I'm not using SAMS yet. I copied 4 textures to RAM, and that's at least as fast as using SAMS. I also thought about optimizing the sky/floor/monochrome wall drawing, but I don't think it's worthwhile to unroll those loops entirely unless the sky/floor are also textured. In this video I doubled the number of pixels written per wall/floor iteration from 4 to 8, and maybe you can see a slight difference, but I don't think unrolling those loop any further will have any visible effect.

Just to note that in the optimized version that I presented I'm not handling columns taller than the screen correctly, which is apparent when you move close to the walls. The simple solution will be to add a few more ROM banks to deal with those additional heights.

Here we go: the time for the drawing routine has been cut in half, resulting in a frame rate of 4-5 FPS. texcaster.rpk texcaster8.bin

It's still a very good suggestion, and I'm almost there. Before this optimization, the routines that take long time are (approximately): - Cast rays: 200,000 cycles - Draw screen: 1,000,000 cycles - Copy screen to VDP: 200,000 cycles With 3,000,000 cycles per second, 1,400,000 cycles correspond to approximately 2 frames per second. The 400,000 cycles from the first and last routine will still be there with the optimization, but the hope is to make a good cut in the middle one.

There isn't any non-mapped part of the ROM. A cartridge in the cartridge slot can only be mapped into one 8K memory region, and the standard cartridge design maps all 8K as one page.

I did all the ground work of adding the unrolled texture drawing code to the ROM cartridge before I realized there is a big problem: the textures themselves are also in the ROM cart and it is not possible to map two banks of the cart into the CPU address space at the same time. The good news is that I still have room in RAM to copy the current textures over, so I'm able to make a demo to see the effects of unrolling the drawing code, but that wouldn't work in a game with lots of textures. The only solution I can think of is to use SAMS memory, which allows multiple 4K pages mapped at different locations.

You can also manually enable sound for a website. In Chrome, for instance, by clicking the Info or Padlock icon next to the URL and choosing Site Settings.

Hmm, that would probably produce better results on the 9918A since you wouldn't be limited to the fat pixels, but I don't know how fast it would be. Are there any MSX games using this technique?

It took me a while to understand what you're suggesting, and it sounds like an excellent idea, but I think it would take more than a few KB: A half height column is 96 pixels, and the lower limit per pixel is one 2 byte instruction, so that's 192 bytes per column, or 18 KB for all 96 different heights that fit on screen. But there are also oversized columns that don't fit on screen, but still need to be rendered to the full screen height, which takes a lot more bytes. The simplest code is when the height of the texture is the same as the texture height. Then each instruction is writing exactly one byte: movb *r0+,*r3+ ; Write to screen buffer and increment movb *r0+,*r3+ ; Write to screen buffer and increment movb *r0+,*r3+ ; Write to screen buffer and increment ... If the screen height is taller than the texture height, some of the texture bytes will be written more than once: movb *r0,*r3+ ; Write to screen buffer movb *r0,*r3+ ; Write to screen buffer movb *r0+,*r3+ ; Write to screen buffer and increment ... If the screen height is smaller than the texture height we have to skip some texture bytes: movb *r0+,*r3+ ; Write to screen buffer and increment inc r0 ; Increment movb *r0+,*r3+ ; Write to screen buffer and increment inc r0 ; Increment ... If we need to skip multiple bytes it will be faster to use ai (add immediate) instructions. I assume that in most cases groups of instructions would repeat themselves periodically, so we could add loops, which may be what we need to fit the code into memory.

Yes I'm going to reduce the size, but C64 has a full screen resolution of 160x200 in multicolor mode, while we have only 64x192, so it's best not to reduce the horizontal resolution any further. Moving into a dungeon is going to reduce the distance the rays have to travel in most cases. But unlike the demo everything will be textured - also floor and ceiling. Unfortunately the 9918A has few dark colors, so it might end up looking like a very shiny dungeon. I'm not sure that EOB was using a ray caster. Maybe there is a faster algorithm for the case with only 4 directions where you always move a whole square?

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?