Small update: finished a lot of conceptual work with the move system, so now the real coding can resume . There are a total of 90 different techniques in the game.

Yeah, you could either use 3 8x8 sprites or the bitmap command. But the bitmap command is slow and rather confusing, so you're probably better off with 3 8x8 sprites that have 2 blank columns at the end

that thing puts my raycasting engine to shame XP I'm interested in where it'll go though! When you think about it, raycasters aren't even true 3D since there's only 2 planes of movement

Okay, figured out generally what's wrong with the engine. It involves the necessity of scaling all my numbers by 128*8 rather than 128, so I think the engine will need to be (almost) completely rewritten. It shouldn't be too difficult though

looking good I like how you use the backbuffer for collision testing

Holy crap.

btw, I'm going to clarify in case this wasn't clear from the beginning, this project is intended to allow other people to make 3d games with Axe, it's an engine. Of course, I might end up making something with it myself, but it is open source and anyone can use the code to make their own game as long as you credit me appropriately

Couldn't you just reduce the resolution, but not the screen size? That might double the speed. However, textures aren't really necessary I think. Do you think adding sprites would be hard, btw? (If they are scaled, I would recommend that each possible zoom is pre-rendered and stored into memory prior starting a level to speed rendering up.

That's an interesting idea, and wouldn't be hard to implement. Sprites I think wouldn't be too hard as long as they are prerendered to a specific set of sizes. I think it should support a couple sizes: probably two sizes, large and small. (as in a small object like the barrels in Doom and the big enemies along with their respective zoom levels) What do you guys think?

Also I will try that optimization, and probably will change the map to 64x64. I was surprised that the byte checking was so much slower as well. However all these changes will mean that I'm going to have to create a map editor/sprite editor, which might take a little while.

EDIT: However, first I want to tighten up the raycasting process as described on the 1st page by Runer112, and get rid of the fishbowl effect. Also I think I get how to do textures now, but I have to do the above stuff first

So I'm running into some rather unavoidable issues: the current method of all testing for collision (of both the rays and the player) is with pxl-test on the backbuffer. Yesterday I tried changing the map to bytes, and using basic array checking ({Y*96+X+Pointer}) so that I could then add support for different types of walls (like the transparent ones), and it runs really slow, even after adding Runer's assembly code. I can't think of any way to improve it

It's not unbearably slow, but I can tell that if I decided to add textures or scaled sprites, it probably wouldn't make it

Progress will continue, but at the best I think we're only going to see 4bit variation in the wall 'types' (done by or-ing two buffers over each other)

edit: Another alternative could be to reduce the screen size, like in Gemini, but I'm kind of iffy on that