Author Topic: Wolfenstein/RPG engine preview 1  (Read 2114 times)

0 Members and 1 Guest are viewing this topic.

Offline Optimus

  • 464 Plus
  • *****
  • Posts: 347
  • Country: gr
  • Liked: 148
Re: Wolfenstein/RPG engine preview 1
« Reply #10 on: 20:11, 07 October 16 »
I guess in the free-movement version, some form of keeping the player from the wall could be implemented too?


It's already there, I just need to put bigger distances. But with bigger distances it feels more crumped, like there is something invisible between you and the wall.
Not saying it can't be fixed, I just have to remember what it was, maybe it's the fact I haven't generated very close zoom for columns because I already used unrolled codes taking a lot of memory. Or maybe it's a bug. But I remember at some point the rpg version would make it easier to avoid these problems, reduce some memory usage, and anyway I love dungeon crawlers so I really decided towards that direction for more than one reason :)


I guess the cart version can have a better palette and fades?


Definitelly I will add support for plus palette, it's easy to do.
On the plus side I could fade the wall/ceiling with 2-3 bands of colors with the raster interupts easy without much CPU loss. On the regular CPC, maybe changing the wall rendering code (which also writes the floor ceiling vertically in one swipe) could do the same, not sure what the impact on memory. Right now the rpg version has the dull black, because the way the columns fade, with the old colored floors even if dark, it looked odd.

Offline Puresox

  • 6128 Plus
  • ******
  • Posts: 1.286
  • Country: 00
  • Liked: 239
Re: Wolfenstein/RPG engine preview 1
« Reply #11 on: 20:28, 07 October 16 »
How much memory does the basic 64 version use?

Offline Sykobee (Briggsy)

  • 6128 Plus
  • ******
  • Posts: 587
  • Country: gb
  • Liked: 180
Re: Wolfenstein/RPG engine preview 1
« Reply #12 on: 23:31, 08 October 16 »
Is it possible for the engine to have different graphics for different walls, and if so, what are the limitations? And sizes? Graphics format? And where is the gfx and map stored in the executable... :D


I've always thought that a RPG was the best use for this type of engine on the CPC, simply due to the FPS issues. Rendering enemies/sprites into the view, scaled, isn't going to make things fast!

Offline Puresox

  • 6128 Plus
  • ******
  • Posts: 1.286
  • Country: 00
  • Liked: 239
Re: Wolfenstein/RPG engine preview 1
« Reply #13 on: 23:54, 08 October 16 »
How much is there left to play with , using the engine?

Offline Misel982001

  • CPC664
  • ***
  • Posts: 139
  • Country: gr
  • Writing CPC Reviews....Keeping our Memories Alive!
  • Liked: 58
Re: Wolfenstein/RPG engine preview 1
« Reply #14 on: 14:55, 09 October 16 »
This is pretty good. I remember back in 1992 when Doom was out, that I kept thinking of why a CPC cannot have a simple corridor shooter. It seems that after 24 years it is going to finally have one.... :o

Offline Optimus

  • 464 Plus
  • *****
  • Posts: 347
  • Country: gr
  • Liked: 148
Re: Wolfenstein/RPG engine preview 1
« Reply #15 on: 12:21, 10 October 16 »
How much memory does the basic 64 version use?


Generally, I waste 16k for unroll codes of wall rendering, then each screen buffer will of course waste 16k (there are some empty gaps to store stuff in the future because I might be using 64byte width iirc), I place the code in another 16k buffer, it's not full yet. The textures are given 8k of space right now because I will need the other 8k for sprites.


I will explain more and answer in more detail later, I am just typing from mobile now :P

Offline Optimus

  • 464 Plus
  • *****
  • Posts: 347
  • Country: gr
  • Liked: 148
Re: Wolfenstein/RPG engine preview 1
« Reply #16 on: 15:16, 10 October 16 »
Yes there can be more textures of course.
The texture size is 32*32, so I could normally fit 8 unique textures. However I am using a column offset mapping that allows for more. So for example I can have a 8*32 stored texture that tiles on X with minimal performance loss. Or the door on the rpg is really 16*32 mirrored. This will allow for some other tricks, like if you have a plain wall and then you want the walk with a lock or a torch, you can reuse columns from the plain wall combine with very few additional columns from wall with livk/torch, instead if wasting full 3 texture space for 3 versions of the same wall.

However less space is there in the fade by distance version. I am not doing realtime shading, I would have to change the unroll codes for that and need more space. I am just creating four versions of darker texture columns. So it would mean 2k for all textures. I need to think how to tackle this, or if I will reduce fade steps.

Offline Sykobee (Briggsy)

  • 6128 Plus
  • ******
  • Posts: 587
  • Country: gb
  • Liked: 180
Re: Wolfenstein/RPG engine preview 1
« Reply #17 on: 18:06, 10 October 16 »
The column based texture storage sounds quite clever. I guess with careful design you could get a lot of variety (plain painted walls would surely only need one column).


Are the columns pixels, or bytes (pixel pairs, the RPG screenshot suggests that it's pairs of pixels making up a column)?


I look forward to the next video and tech update :-)

Offline Optimus

  • 464 Plus
  • *****
  • Posts: 347
  • Country: gr
  • Liked: 148
Re: Wolfenstein/RPG engine preview 1
« Reply #18 on: 21:46, 10 October 16 »
The column based texture storage sounds quite clever. I guess with careful design you could get a lot of variety (plain painted walls would surely only need one column).


Are the columns pixels, or bytes (pixel pairs, the RPG screenshot suggests that it's pairs of pixels making up a column)?


I look forward to the next video and tech update :-)


Yes, the columns are bytes. If it was pixels I would had to somehow connect left/right pixel pair, I would have to think of a quite different approach either more unroll codes and still slower or forget about unroll codes and render things with smaller code which would save a lot of memory. But I don't know about speed, even though now it's mostly taken in the raycaster math rather than the wall rendering which is pretty fast.


Few zoom sprites could be possible with small sprites and not allowing too close zoom. Smaller sprites (like 8*8, 8*16, 16*8, depending on the enemy or item) would be finer for the limited memory I will still plan to use them on the rpg. Afterall much more speed is wasted on raycasting atm. I will try some brute force in C first and then assembly.


p.s. Hopefully I'll write some more in my blog. Right now I don't have much internet and I was typing from my mobile.