It reminds me of a trick when trying to center or level something. If it looks right, then it is right.
Yes probably you are right. I am just unsure about the parameters for the input/output sections and if i need clobbers. The inline assembly syntax is quite cryptic for me and I never did it before. Just afraid of side effects that are visible at a later stage.
Is that really faster?
I do not know avr opcodes but once disassembling a x86 program I learned how they use magic numbers to divide by multiplying and getting the overflow. So if the compiler is not doing that optimization, you could find the magic number for 64: http://www.hackersdelight.org/magic.htm and use it in 2 contiguous variables.
Maybe asm magic is not needed
Yes it is really faster. The compiler was generating a loop (6 iterations) and was performing lsl, asr, adc combination. This is actually correct but for my special use case it was consuming too much cycles. Normally a right shift by 6 would do it also but the AVR can only shift by 1 per lsr instruction and also you need to handle the 16bit value in two 8 bit registers. That creates more overhead. The asm code from above takes 7 cycles whereas the compiler generated code was something like 5x6 cycles.
Many thanks for your hints. I did not know this. It is quite some stuff to read but looks very helpful. Maybe I can find even a much nicer solution. Maybe I find a way to write it down in C rather than asm.
I only took a quick look but perhaps pair your left shifts with ADC (or shift + carry) instead of of INC/SBRC. You don’t need to do that manually, that’s what the carry flag is for.
Ah I see. You are right! Many thanks. I’ll change that. It will make things more clear.
Just ordered the book. It’s a fantastic source of inspiration! Thank’s for pointing it out.
This available yet? I’m really interested in the performance you’ve got here… I’d love to see it… First person…
Just featured in the blog! https://arduboy.com/fps-fires-em-up/
Thanks for featuring it. I think it will take a few more weeks before I can release it. Added the enemies recently and collectible items. Will share a video on that during the weekend. Then I still need to do all the textures and other graphics, sound and so on but the engine should be ready from then on. I will share it as soon as possible.
The Arduboy Game Jam is coming soon and maybe I will attend. This will maybe add some delay
As this game will eat up most of the resources I thought of making just a single big level per .hex file and post a “secret” code when finishing. Then with awesome tools like ArduboyMate and all the nice programs to upload we could put each level in a dedicated image and asking for the “secret” password at the beginning. Like in the very old days where saving was not possible.
We could even think of a kind of a community game where the levels are continually created by other users.
This is great we should think about a way to feature games that have level editors and stuff like that!
Just a small ping here. The project is not dead. I am just too busy at the moment with other tasks. Maybe have to wait another month until I can continue. Sad, but once I am back I will continue it and release the code. Sorry for being so slow
This is a seriously great looking game … hope you get back to it!
It’s understandable, raycasting is difficult even when you have colour.
(I made a raycaster once, but it was ultimately just a port of Lode Vandevenne’s code using pure SDL2 instead of his SDL2 wrapper code.)
Thank you all. Yes it is quite difficult even if the environment is very limited. Technically I think the engine is done. When I find the time I have to add a few performance improvements that I have already finished and add real graphics and not just dummy’s as in the video (I am not an artist).
Music will be another problem but I think I will just add a few simple sounds to give it at least a little atmosphere.
Maybe I will have a little time here and there but mostly I have to do other things for the next weeks.
After a long break due to some private tasks here is a small update
I added moving walls, collectable items and some further optimizations. Next is to fix collision detection with moving walls and proceed with sprites and enemies. These still give me some headaches.
I kind of underestimated the work required for a game like this but it is still a lot of fun and it is something I really like to finish.
The performance is off the charts!
I could not resist and played a little more with moveable walls. This add so e nice possibilities to create puzzle games. I like these walls. They make it more exciting… getting splattered by a moving wall like in ROTT or creating some dungeon crawler.
With a little change in the code the player could push these around. This would make the levels more interesting.
Still needs proper collision detection with these walls. Will try to finish that the next days.
Btw if anyone has nice textures for the walls you can send it to me any time. They are 32x32px in size. Currently I am just using some debug image and I am not a good artist.
This is amazing! I can’t wait until a full version comes out! Also, could you add a download link to your progress?
Little update. Spare time is rare cuff … ok, sometimes I really struggle with things, like in that case the movement. Since my last add of movable walls I had to rework the movement. Still it is not finished and there are also quite some glitches during rendering but I could add a few more things:
- Doors can be locked, so you will need a key to unlock.
- Flaky doors that open/close randomly.
- Better movement (still WIP)
The image is big as it contains a lot of debug code. Anyway, some may want to try it as tech demo.
This time no video. You can download the .hex file under preview_binaries here:
Or play it in ProjectABE:
And for the extra look and feel (thx to @FManga) :
B - Fire
A - Action (like open the door)
Graphics and level are just for testing.