Pokitto is on the way, what games should I make?

That means it can’t find PokittoLib/POKITTO_CORE/FONTS/TIC806x6.cpp.
Here PokittoLib refers to the Pokitto folder inside the lib’s repo, not the entire repo.

2 Likes

It’s doing something! Thanks :slight_smile: Will report back soon.

EDIT:

Yep, compiles, the screen bug is gone, seems to even run faster. However, when I run the program, it’s something completely different from what I see in the simulator :smiley: There is no fog, I can’t go up and down and the map is different. This blows my mind, I have to investigate what’s happening.

EDIT:

Works now! I had an old version of the raycastlib around that got included instead of the new one.

EDIT:

However mode 13 is not working for me in the simulator (shows just a black screen). I tried both this and this. Official examples of mode 13 aren’t working either. Mode 15 is working.

yet another EDIT:

Trying out the emulator – good new is it runs. Bad news is that I can’t compile mode 13 to bin – when I put #define PROJ_SCREENMODE 3 to My_settings.h, compiler says

../PokittoLib/POKITTO_CORE/PokittoDisplay.h:205:107: error: 'LCDWIDTH' was not declared in this scope

(If I define it, there are more undefined macros.)

1 Like

try #define PROJ_MODE13 1 instead.

#define PROJ_SCREENMODE MODE13

This one worked.

EDIT:

Still it only has 16 colors in the palette, others are black, whatever I set them to. It’s like that even when I upload it to Pokitto. Anyway, I’ll work with 16 colors for now :smiley:

1 Like

That is not right. The right setting is

PROJ_SCREENMODE 13

Tried that one too, it does the same thing. Also, why does it say PROJ_SCREENMODE = 3 here?

EDIT:

Summary
unsigned short pal[256];

...

p.begin();

for (int i = 0; i < 16; ++i)                                                    
  pal[i] = p.display.RGBto565(255-i,255-i,255-i);

p.display.load565Palette(&pal[0]);
...

uint8_t a = 0;                                                                  

for (uint8_t j = 0; j < 88; ++j)                                                
  for (uint8_t i = 0; i < 110; ++i)                                               
  {                                                                               
    p.display.drawPixel(i,j,a);                                                     
    ++a;                                                                            
  }

image

Fog with ramps instead of dithering:

out5

EDIT:

Also WOW, I’m getting 50 FPS now! I turned on -O3 plus applied @FManga’s tricks. (I guess it could go even higher – I got 25 FPS when I had target set to 30. Now I have it set to 60 ang get 50.)

6 Likes

I usually set the fps target to 255.

We know you are a hot coder but isn’t that bragging just a little bit over the top? :wink:

3 Likes

ceiling are working (now it’s just mirrored floor):

out6

EDIT: Also mode 13 somehow works now, so I can start working on texturing.

So much better with more colors!

image

6 Likes

And we have texturing :slight_smile:

out8

You can see quite the aliasing in this one, MIP maps would help, but I’m afraid of performance. Haven’t tried Pokitto yet.

5 Likes

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 :smiley:


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:

    1. Before rendering walls, make a list of sprites visible on screen and map their positions to screen-space (but don’t draw yet).
    2. 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.
    3. 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 :slight_smile:

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 :confused: 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 :slight_smile:

Also my program randomly gets hard stuck, in (according to the Emulator) Pokitto::Core::update for some reason :confused:

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?