Beautifull, maybe a little too much roll effect atm but i think that it’s too show how fine it’s works. The graphical result is really beautiful. (And please continue your Gamebuino works from the Gamebuino on the META too). The black and white works on Arduboy is well contrasted, outline are clean. You’ll be able to complete the Wolfenboy soon i think with the advance of your motor if you have already the levels done on Gamebuino to insert in your motor. The final game will be amazing, i think
Couldn’t the fake tilt be made into real tilt? Instead of just offsetting the points in vertical direction (that seems to be what you’re doing) rotate them around the screen center. It would require sin and cos though, but maybe some clever precomputation would help. Or do up-down movement of the camera instead (like e.g. in Doom).
Would you mind adding a license so that someone can expand on it and make it a game? Or are you planning to expand it further yourself?
Just realised that I never replied to any of the questions!
@Jean-Charles_Lebeau : I don’t have any plans to do any projects for the Gamebuino META as I don’t actually own one. If you want to port any of my games or demos then feel free to. I’m happy to answer any questions that you have about the code
Thanks! It would take a bit of work to make a real tilt due to the way the rendering is set up. I think for the slight rotation amounts this works ok though. Could do a camera bob up/down movement instead of the tilt.
I have added an MIT license to the demo so it is free to be copied, picked apart, built upon. I don’t have any plans right now to expand this to a full game
I think that the current vector style / line drawing works really nicely on the low resolution display and scaling the lines would probably spoil this.
Thanks Kevin! Technically it isn’t ray casting which is why it was possible to do the vector style, which was the aim of this demo. Performance was really important too. It does get a big sluggish if sprites take up too much of the screen though.
Being too close to the sprites has always been a problem for this type of engine. The one I worked on a long time ago would pretty much freeze the system if you got too close. It’s kind of a weird bug isn’t it? I guess it has to do with how it is drawn but I wonder if there is a way to fix it.
It’s because the closer the sprite, the larger it is, and therefore needs more CPU cycles to render it out. In my implementation I use a look up table to speed up the process of calculating the scaling to avoid any expensive mathematical operations (e.g. divide).
It could probably be sped up without the outline drawing effect. Also not sure if the calls to PutPixel() are getting inlined or not by the compiler. Could probably be faster still if written in hand tweaked ASM!
The sprite disappearing?
(I assumed that was because the player had just walked through it.)
Or the warning LED lighting up?
The easiest way to tell is to put __attribute__((noinline))/[[gnu::noinline]] and __attribute__((always_inline))/[[gnu::always_inline]] on PutPixel.
If noinline increases the code size and always_inline has no effect, then it’s being inlined.
If always_inline reduces the code size and noinline has no effect, then it’s not being inlined.
If both give different results, mysterious things are happening.
I think the bigger problem is that drawing pixel-by-pixel is slow.
If you could find a way to draw column by column then you’d save a lot of shifting and masking.
In fact, I think even having a 1 byte buffer for the column and writing into that before copying it to the screen would save some processing because you could cache the row offset after calculating it (i.e a single multiply instead of 8) and possibly save some other calculations.
For example, instead of needing to do bit = 1 << (y & 7); (or the equivalent),
you’d be able to maintain a single mask variable (e.g. uint8_t mask = 1),
and then just do mask <<= 1 once per iteration.
I can never remember where objdump.exe is.
(I really need to find it, rename it and put it on my %PATH% or something.)
Even when I can find it, the assembly dump is always massive.
There’s no rush as far as I’m concerned.
If you do get back to it at any point,
have a look at my fork and decide if you like any of the changes.
I can make a PR or you can commit them yourself.
(But if you commit the changes yourself,
I’d appreaciate it if you could make me a co-author.)
Had a quick look at your fork and it looks like you’ve been busy! Looks like most of your commits are style changes but also a few optimisations too. One interesting difference in DrawWallSegment() was your change from this: