Asmusr

Cool

The time it takes to cast a rays is proportional to the max number of steps, but only if it doesn't hit anything. Currently the max steps is 24, so reducing it to 8 would have an effect. But drawing the screen also takes time, so maybe the overall time per frame would be reduced by 10-20%? However, I'm not sure how you would draw fog?

Right, but updating patterns would be a lot slower. I have thought about using multi-color mode because that can be arranged in true columns and could also support low-res textures, but I think it would be too slow.

Cool. I usually stay far away from self modifying code, but in this case it's worth it.

But you do understand: 🙂

It's a 117MB file. Maybe that's why it doesn't show up so quickly?

I'm familiar with that algorithm from when I made a raycaster for the F18A, but for this project I want something simpler and faster.

According to this page http://www.permadi.com/tutorial/raycast/rayc8.html fisheye correction should be done by multiplying the height with the cosine of the angle between the ray and the player's direction, which makes a lot of sense, but if I do that the walls bend up at the edges instead of down like they do now. I can't think of any explanation except that my algorithm is just too inaccurate and/or the resolution too low.

In which emulator?

Like enemies and treasure? I think it might be possible to draw something, but the scaling would be a problem, and you would soon run of of characters.

Does MAME ignore the 16K/4K flag in VDP reg 1?

Actually it's me who have 'fixed' js99er to show the effect of running with 4K video memory. If you set VDP reg 1 to >e1 instead of >61 thus enabling 16K video memory everything should be fine.

You're right, the issue in js99er seems to be that the cart doesn't work after a reset. I must be forgetting to reset some part of the system. In Classic99 QI3199.018 I get a the attached screenshot if a rename the file to vepseuc.bin and open it as a user cart (or by drad and drop). It sets VDP reg 1 to >61, which I believe means 4K mode. If I patch byte >87 to >e1 it works in Classic99.

I can think of many reasons why some home-grown game projects are never completed: It took too long time to develop The original idea didn't work out It wasn't possible to make the code work as expected It wasn't possible to achieve high enough performance It was never meant to be a full game Bad or missing feedback from the community Loss of interest/desire to do something else Copyright issues I don't think lack of storage space has ever been the reason, unfortunately.

I decided to see how much speed I could squeeze out of a character based raycaster with only 32 columns. The result can be seen here: https://youtu.be/Y_WR974T_Ak You can also run it yourself using one of the attached files. The frame rate is 15-20 FPS, so this is quite within the limits of a playable game. The question is whether it's too ugly? The algorithm is a simple raycaster where reality is sacrificed for speed. The world is divided into 128 directions, and for each direction I pre-calculate a unit vector (cos(a), sin(a)) in Java and store it as two 8.8 fixed point numbers, i.e. multiply floating point number by 256, round, and store in a 16-bit word. So the output from the Java program is a list of 128 x values and 128 y values as TI-99/4A assembly DATA statements. The player's position is also stored as two 8.8 fixed point numbers (x and y) and the player's direction is stored as one of the 128 directions. For each frame we cast 32 rays from the player's position, each in a different direction, with the player's current direction at the center, so from direction - 16 to direction + 15. Each ray start with the player's position, and we keep adding the unit vector in the given direction until we hit a wall or give up. So for each iteration we need to check what the map contains at the given position. To do this as quickly as possible we make the map width 256 so the map address can be calculated as 256 * y + x + base, which it's very fast to do in assembly. So the central loop of the raycaster looks like this, where (r0,r1) contains the current (x,y) position, (r3,r4) contains directional unit vector, and r8 is a counter for max iterations: cast_ray_1: a r3,r0 ; x += xdir a r4,r1 ; y += ydir movb r1,r6 ; y -> r6 msb movb r0,*r5 ; x -> r6 lsb (for a bit of speed, r5 contains the address of r6 lsb) movb @map(r6),r7 ; Get map entry jne cast_ray_2 ; Not zero is a hit dec r8 ; Distance count down jne cast_ray_1 ; Loop until we give up The value of r8 after the loop determines the distance we have traveled, and the value of r7 determines what we have hit. From the distance we can calculate the height of the wall at the given screen column. The formula is something like max_height / distance, but I use a look-up table. Calculating distances from a single point is resulting in a fish-eye view of the world, as you can see in the demo. A more sophisticated algorithm would calculate the perpendicular distance to the view plane instead. I think it should be possible to fix this without sacrificing speed by having an additional correction look-up table. We now have a height for the walls for each of the 32 screen columns. For each column we want to draw a strip of sky, then a strip of wall, and finally a strip of floor. To do this most efficiently I have pre-drawn the columns at different wall heights in Magellan. That also makes it easy to add the primitive 'textures' you see on the demo. Drawing columns one by one is bad for performance because you have to set up the VDP write address for each row, so instead we set up the write address once and then draw one byte from each column in turn. To fetch the bytes to draw we set up a pointer for each column that point to the right column data. The drawing loop looks like this: upload_screen_loop: li r1,column_ptrs li r2,screen_width upload_screen_loop_1: mov *r1,r0 ; Get column pointer movb *r0+,*r15 ; Write byte to VDP (r15 contains VDPWD) mov r0,*r1+ ; Write pointer back dec r2 jne upload_screen_loop_1 ; Next column dec r3 jne upload_screen_loop ; Next row rt Finally, to push the last bit of performance out of the TI-99/4A, I run the two central loops from scratch pad RAM. The code is on GitHub: https://github.com/Rasmus-M/raycaster raycaster.dsk raycaster.rpk raycaster8.bin See also:

It appears to be setting the VDP into 4K mode. So it doesn't work in JS99'er either if you turn off F18A emulation. But another reason it may not be working directly in Classic99 is that it requires RAM at >7000->7fff. So I think you would need to set up a special configuration to run it.

I would have thought that the only way to produce graphics like that would be to pre-render every object and load it from a large ROM cartridge. Are you planning to render directly to the VDP or to a RAM buffer first? I have some ideas for a linear screen buffer in CPU RAM and how to transfer it to the VDP, which I have never used. Indeed 16-bit multiplications are nice, but on the TI they are not signed. Or actually, if the result stays inside 16-bit they are signed (I think @mizapf made a proof for that a few (6-7) years ago). If you need any help with the TI stuff I would be more than happy to contribute.

It would be incredibly cool if you could produce something like the above video on the TI-99/4A.

I have given this some thought, and I think a frame rate close to 10 would be possible with 32 rays/columns. However, it would require more than 8K space because some things would have to be pre-calculated. I think I may give it a try...

As long as it's not PEBs. 🙂

Thanks. That's a much better approach than messing around with FDRs. And I have actually implemented this in my custom disk controller in js99er.net - I just forgot about it.

What is the best approach if you want to read from a named file sector by sector? I mean, how do you know which sectors to read?

It looks like different parts of the cyan sprite are swapped, but it's difficult to tell from the screenshot.

Perhaps you could post a screen shot?

I just stumbled over this, and to be honest I just love to hear any rendering of the Monkey Island II music. This was my own demo: