Wow, fast progress!
I do not think mipmaps affect performance much, at least if the texture sizes are power of 2. The sram is very fast and multiplication is 1 cycle.
2 Likes
http://www.catb.org/jargon/html/L/larval-stage.html 
Actually you might be right, I might be even able to avoid a conditional jump with some clever arithmetics.
Current issue:
How to determine the visibility of sprites?
With “normal” raycasting (like wolf3D) this is simple: you have a 1D z-buffer. But with raycasting++ I’d need a complete 2D z-buffer, because obviously the depth varies over each column. But 2D z-buffer isn’t an option because memory size. What I’ve been thinking of:
-
Semi-2D z-buffer: full resolution in X direction and much smaller resolution in Y, also quantize depth to only a few bits. Not very good because it would look ugly and would still take a lot of space.
-
Determine the visibility during rendering like this:
- Before rendering walls, make a list of sprites visible on screen and map their positions to screen-space (but don’t draw yet).
- Draw the walls. If a pixel is being drawn at the place of any sprite of the list, compare depths and discard the sprite if it’s behind the pixel.
- Draw the sprites that remained in the list over the walls.
This is very good for memory, but not so much for performance, because each pixel has to compare it’s coordinates to each sprite from the list (could be done in a clever way with sorting etc., but still). This will be slower the more sprites are visible at the time. This also won’t be able to clip the sprites – it treats them as single pixels, but that we’ll have to live it I guess.
I’ll have to think about this some more. Feel free to suggest ideas 
1 Like
It looks nice, but… to be honest, the more I see it, the more it makes me nauseous because the texture coordinates (especially the U one) aren’t transformed properly.
For the sprites, I’d check what DOOM is doing for handling the various floors, as your engine is now somewhat closer to DOOM than to Wolfenstein for that purpose
I’ve just looked and the Doom engine is a lot different, mine is still much closer to the Wolf one. Doom doesn’t use raycasting, it draws the walls directly – the visibility is determined by BSP trees. The engine has a list of wall edges and clips sprites against that. This doesn’t fit my engine though 
I think I’m gonna try the second method I mentioned above and will see.
1D z buffer does the job okay – there aren’t so many situations where the errors can be seen. I could do the semi-2D buffer to improve it a bit.
For sorting the sprites I’ve used @FManga bubble sort trick. It’s really super clever
Also my program randomly gets hard stuck, in (according to the Emulator) Pokitto::Core::update for some reason
1 Like
Looks like it doesn’t get stuck on hardware, so it’s probably an emulator bug.
Are you using the latest version?
I ran the emulator in profiler mode and it pointed out that the division here:
int intensity = 7 - (depth * 7) / (UNITS_PER_SQUARE * 5);
results in a function call to __divsi3. That’s probably not good for performance in a function that is called for every pixel you draw, compared to shifting right.
The profiler also points out that a lot of time is spent doing square roots.
Any reason why you scale wall textures vertically but you don’t scale them horizontally? It looks odd how they stretch as you get closer.
1 Like
So I just did a git pull and the emulator doesn’t show anything on screen, even with a different bin. Let me check this. The version I’ve been using until now was only a few days old.
Also I just found a weird arithmetic bug, I have screen capped the difference in behavior in the emulator and on the actual Pokitto. If I get this version to run and the bug is still there, I’ll post it to the emulator thread.
Thanks – this is part of a code that’s extremely WIP, I haven’t done any optimizations there. Once I catch bugs, I’ll get to this.
The new profiling feature is awesome BTW, I’ll make use of it very soon.
EDIT: Okay, the void screen bug happens after commit ab4e0b2ed056d0b713fbe9f7ddd009bea9b33163. The previous one works fine. I guess it’s related to the multithreaded rendering.
Odd. Does this happen with the build that is in the releases page?
Yes (the source version, binary doesn’t run because can’t find some .so library).
sprites and the z-buffer:
8 Likes
Can we please try that on hardware?
2 Likes
On Pokitto currently 25 FPS – but that’s with all features on and without optimized Pokitto code (so far I only try to optimize the library, the main program is messy), so it might go a bit higher. I also had to increase ray sampling because of the textures which dropped FPS a lot. Still this could be okay for a slow dungeon game. You can lower visibility etc. to increase performance. You could also draw a GUI bar somewhere to lower the resolution a bit 
If you don’t use textures, you can subsample more without noticing and go over 50 FPS, which could be good for a shooter or maybe even racing. Lack of texture sampling also adds some speed and you could also go with the vanilla single-hit raycasting which will be even faster.
3 Likes
This is amazing!! This is really a great thing to see for inspiration as to what can be done with the Pokitto!
1 Like
Calling in Blender to help design the demo level 
I think I’ll make at least two demos:
- A full feature showoff.
- Vanilla 1D raycasting with higher FPS.
So that people have two starting points, depending on what’s closer to the desired game.
EDIT:
Or maybe even a Minecraft-like demo where you could edit the world. We’ll see 
It could work like this: The world would be infinite, generated procedurally and the edits would be saved in a list with limited size so that the oldest changes would simply seize to exist as you make new ones. Each change would be a coordinate and height difference against the original world. Problem is that the player can stand on an edited square, then make a change, which will undo the edit of the square they’re standing on, which will catapult the player into space But for a demo it’s a good enough solution.
EDIT:
So this is what I’ve done today – ceilings are separate now and multiple textures are allowed – this is the level I’ve made in Blender. Also fixed a few bugs, but some remain (e.g. weird texture mapping). But kinda looks like a nice horror game now.
8 Likes
omg that looks nuts, so this is using mode 13?
i see the floor and cealing are using single colors, would it be nuts to use that fzero rendering for those ?
sorry to ask to much questions, have you looked at drawing directly to the screen? it might give higher color range or resolution
Looks fantastic!
Are you directly importing a Blender-created file to your project?
Yes, that would be faster too but then you have to deal with flickering. You have to write each screen pixel only once per frame. Otherwise you can easily introduce flickering.
Mode 13, yes.
That would be too slow now, but once I get to the demo with the simpler version of raycasting, I may try texturing the floor.
I think I’m doing it – I copied in a code that @FManga suggested that I think is doing this.
EDIT:
Hmmm… drawing directly to screenbuffer instantly displays it, while DrawPixel(…) uses double buffering? I do need to overwrite some pixels when drawing sprites over the rendered background.
EDIT2:
Okay, looking at the library source I think I am not drawing directly to screen, just directly to the screen buffer. I can’t draw directly to the screen because of sprites, so this is probably the best I can do.
Yes, otherwise you should combine each scanline with sprite and scene pixels before drawing directly to the screen. Screen buffers make life easier and @FManga has optimized screen buffer to LCD writes to execute very fast.
1 Like
you can gain more colors with using a 16bit scanline buffer. (woops hanski got before me XD)
if you want more colors wierd trick could be by swapping the pallat midway the screen to add aditionals color for the floor and cealing
but thats asuming you can change the foor colors by portal id or something
its still insanly impresive
2 Likes