Right … so Dark and Under uses 100% of both, almost. Sounds like a match made in heaven
To be honest, I don’t think D&U’s turn-based mechanics would properly take advantage of a raycasting engine.
I think it would be best suited to either a traditional doom-like FPS or an FPS-RPG game like Barony or Eldtritch (but keep the map one-block tall).
Both could incorporate some of the techniques D&U used for managing the map and enemies,
but the turn based elements and the HUD would be gone (in favour of a more minimalistic HUD).
It would probably be better used for a new project in that case.
Does anyone have plans for a game using this? It would look great!
I would love to … I would like to make a FPS but @igvina and @luxregina may be making the definitive version in their Doom game. Maybe a maze game where you race the clock to complete tasks or simply make it through?
That sounds like a great idea! I would make it, but I know exactly nothing about coding on the arduboy. I will read up and try, though.
One of the issues I can see is having other (fixed and moving) items in the environment that would need to be scaled as you approach them. Obviously this is memory intensive (if using multiple images) or CPU intensive (if you plan to resize them dynamically with generally average results).
Without seeing the code, I wonder how other fixed items can be included in the rendering algorithm. Will you have to let the engine draw the environment then you will have to calculate whether you need to render the item (it may be hidden by a wall) and then, based on its distance from the player) at what size.
I can see memory being a big issue here !
I think if sprites only scaled down then it wouldn’t be too bad.
You would need a custom sprite drawing function, but basically you’d just have to use UV-like coordinates and maybe some lerping.
Now obviously with floats that would be difficult, but with fixed points…
If anything, I think speed would be the issue in this case.
Calculating whether you can see an item or not is probably easier than expected.
I’m pretty sure it could be merged with the ray pass.
Do tell? Do you know of such a library??
I would hope so, but not sure how flexible this engine might be.
Which reminds me, I’m still waiting for it to be added to the quickstart guide:
Though we have a new quickstart guide now anyway, so I guess it’s Kevin I’d have to talk to.
Until we see the code, I’m assuming it’s just a port of the code from Lode Vandevenne’s semi-famous tutorial.
That’s usually what most raycasting implementations are based on because it’s probably the most comprehensive guide on the internet.
I hadn’t seen this reference before - I haven’t read the entire internet yet! - but it looks very comprehensive.
I have read both Lode Vandevenne’s tutorals and F. Permadi’s tutoral in the past. They are both wonderful sources of information on raycasters. Fabien Sanglard’s recent book on Wolfenstein 3D is a great technical book as well. I highly recommend it. My implementation is original with some pieces, such as the collision logic, that I used from another implementation. I tried to create a pretty straightforward version that includes the standard stuff and some original ideas I came up with. I will definitely release the source code soon.
Well, being a moderator, you could have done it yourself . However, I’ve now done it.
Wow what a great reference. He also has quite a good list of books to look at. Many thanks for this great hint!
I just wanted to give a quick update. I ported my Raycaster project to the Gamebuino META. This version includes all of the current features of the Arduboy version and texture mapped walls and doors.
Does the Gamebuino version still use FixedPoints?
Yes, but I had to define FIXED_POINTS_NO_RANDOM to compile.
Here is a HEX file if anyone wants to see it run on an actual Arduboy. Let me know if you have any problems.
In a future version (possibly
v2.0.0, which is due soon™) the random stuff is likely to either be disabled by default, removed or exiled to a separate header.
The random functions have been the single biggest headache of the entire library.
Every single “it doesn’t work on platform X” issue has involved the lack of
As far as I’m aware that change will only negatively affect @filmote’s 1943, but I’m planning to add something in
v1.1.0 that should help to alleviate that.
Looks great. Will you continue working on the Arduboy version like adding texture support?
A Wolfenstein game for Arduboy would be awesome.