Asmusr

It's interesting that this doesn't really require 32K RAM. As my code is now it does, but I think it could run almost as fine from a ROM cart. The only updated data in 32K are the positions of the enemies, and those could be moved to VDP RAM.

I like this solution.

I use the weapon to see the frame rate.

Here's the latest version. I don't have time to write about it now, but it's progressing really well. I fixed an issue with the height calculation which means that the walls are no longer rounded. Your challenge for today: find the two multi color striped areas. raycaster.rpk raycaster8.bin

I want the result 1, 0 or -1 in the register. If you SRA Rx,15 that gives you 0 or -1, but how do you get 1 if Rx > 0?

Yes I will consider that. Do you think 1024 characters is enough or should I double it to 2048?

Is there a clever way in assembly - without tests and jumps - to calculate the sign of a register (if r > 0 then 1 else if r < 0 then -1 else 0)?

I have actually made a new version of Magellan: 4.0.0 beta. It's available from https://magellan.js99er.net/ The main new feature is that you can select a Super Character set with 1024 characters. The idea is that you have a much bigger workspace, for instance when you import an image and want to see how many characters it takes, or you just want a buffer for keeping your draft characters. It's something I did a while back inspired by a discussion I had with @matthew180 and I haven't used it a lot since, so this feature must be considered a beta. Just to be clear, the TI cannot show those characters, so if you export them you're on your own. Other new features include the ability to rotate, flip and mirror whole maps. It's something I added because a had mirrored some maps for my raycaster, and programming the feature was easier than fixing it by hand. You can also flood fill on a map - changing all characters in a region bounded by another character to something else. Since there are many different versions of Java runtime now, and they might not all work with Magellan, I decided to include the last free version of the Oracle JRE 1.8 v 202 with the installers (except for Linux). This is a beta so using it is on your own risk, not that the risk is very high. 🙂

Before Shapchat we had the snaphat. 🤪

Here's the routine I used to draw two columns given top, height and color.

I did that myself (a multicolor renderer without a raycaster) a while back, and I am indeed considering if that's the way to go with this project. You're welcome to try your own renderer with my code, of course.

Hmm...

Exactly. Without anything other than walls very little interaction is possible. But adding big zooming sprites using a limited number of character tiles is quite challenging.

All I can say is that at the moment I'm interested in developing this project further. But there's currently not much to make a game from, and I don't have any specific idea for a game.

Yes I did think of that, but having two holes in the list of column pointers would require some awkward handling in other parts of the code. The code looks like this now, running from 8-bit RAM (34620 cycles): upload_screen_loop: lwpi column_ptrs mov r15,@tmp li r15,vdpwd movb *r0+,*r15 movb *r1+,*r15 movb *r2+,*r15 movb *r3+,*r15 movb *r4+,*r15 movb *r5+,*r15 movb *r6+,*r15 movb *r7+,*r15 movb *r8+,*r15 movb *r9+,*r15 movb *r10+,*r15 movb *r11+,*r15 movb *r12+,*r15 movb *r13+,*r15 movb *r14+,*r15 mov @tmp,r15 movb *r15+,@vdpwd lwpi column_ptrs+32 mov r15,@tmp li r15,vdpwd movb *r0+,*r15 movb *r1+,*r15 movb *r2+,*r15 movb *r3+,*r15 movb *r4+,*r15 movb *r5+,*r15 movb *r6+,*r15 movb *r7+,*r15 movb *r8+,*r15 movb *r9+,*r15 movb *r10+,*r15 movb *r11+,*r15 movb *r12+,*r15 movb *r13+,*r15 movb *r14+,*r15 mov @tmp,r15 movb *r15+,@vdpwd lwpi wrksp dec r3 jne upload_screen_loop ; Next row

I tried the optimization in combination with running from PAD, but it only saved about 5000 clock cycles so I decided save the PAD for something else and revert to running from 8-bit RAM as in post #39.

I found an even faster way to transfer the screen: Let's move the workspace on top of the column pointers, then we can transfer a byte and increment the pointer in one instruction: upload_screen_loop: lwpi column_ptrs movb *r0+,@vdpwd movb *r1+,@vdpwd movb *r2+,@vdpwd movb *r3+,@vdpwd movb *r4+,@vdpwd movb *r5+,@vdpwd movb *r6+,@vdpwd movb *r7+,@vdpwd movb *r8+,@vdpwd movb *r9+,@vdpwd movb *r10+,@vdpwd movb *r11+,@vdpwd movb *r12+,@vdpwd movb *r13+,@vdpwd movb *r14+,@vdpwd movb *r15+,@vdpwd lwpi column_ptrs+32 movb *r0+,@vdpwd movb *r1+,@vdpwd movb *r2+,@vdpwd movb *r3+,@vdpwd movb *r4+,@vdpwd movb *r5+,@vdpwd movb *r6+,@vdpwd movb *r7+,@vdpwd movb *r8+,@vdpwd movb *r9+,@vdpwd movb *r10+,@vdpwd movb *r11+,@vdpwd movb *r12+,@vdpwd movb *r13+,@vdpwd movb *r14+,@vdpwd movb *r15+,@vdpwd lwpi wrksp dec r3 jne upload_screen_loop ; Next row rt Even from 8-bit RAM, this is almost twice as fast as the old routine running from scratch pad (36226 vs. 60270 clock cycles). It could be optimized even further by storing vdpwd in one of the registers, e.g. r15. Then the instructions could be replaced by movb *r0+,*r15, movb *r1+,*r15 and so on, which is faster and takes half the space. We would then need to deal with last column separately, preventing the column pointer from being overwritten.

I have given in and moved to the DDA algorithm. With the simple algorithm I just couldn't figure out an easy way to tell whether I hit an x or an y wall, so I could't change wall color depending on the orientation of the wall. The approach used here https://lodev.org/cgtutor/raycasting.html is great if you have floating point numbers, but with fixed point numbers I don't like divisions, so I have adjusted it to used pre-calculated tables of sines and cosines and only a few multiplications. The result looks a lot better, with clearly defined corners. I have also implemented fish-eye correction, although it still looks a bit weird when you're parallel to a wall (due to too low precision). The speed is more of less the same as before. An added benefit is that the new algorithm doesn't require the map to have a width of 256, because I can trace the ray using a map address instead of fixed point x and y coordinates. I have also implemented a new kind of textures, which means that within a block (the world consists of 256 x 32 blocks) you can choose a different color (column set) for each column with a resolution of 16. It doesn't look great to be honest (resolution is way to low), but it can be used to implement special blocks like doors (there are two on the map). The old way of implementing textures using characters with different patterns still exists, it's not visible in this demo. The next step is to try to add enemies or other objects. The idea is to save the depth of each column during the raycasting, and then, in a second pass, only draw a column of an object if it is in front of the depth buffer entry. It will require changes to the rendering routine, and may require significant changes, like moving to use a buffer in 32K RAM. raycaster.rpk raycaster8.bin

You're just copying a memory range two bytes back? Instead of using indexed addressing I guess it would be faster to set up two registers tmp0 and tmp1 and use auto-increment addressing: ai tmp0,idx.top mov tmp0,tmp1 inct tmp1 ! mov *tmp1+,*tmp0+ dec tmp2 jne -!

It would make the edges of walls less well-defined. It's already pretty bad with the edges, so I'm working on a second version that will make the edges more well-defined and remove the fish-eye distorsion.

Contract form? Are you sure it doesn't commit you to buy? 🙂

I have been thinking about doing something similar by pre-recording a number of animation sequences and storing them on a large ROM cart.