I decided it's time to release a preview of my wolfenstein engine, both the free movement one and the smooth dungeon crawler use of it in a game I planned but never finished last year. Since I am not sure when I will be motivated to continue working on this project, I thought it's good CPCists have the opportunity to move around those mazes and be inspired by what it might be.
Because of the last gamedev compo, it made me make changes to the engine so that it can run in 64k machines and so you have bother 64k/128k editions and GX4000 cartidge. You see few differences like 64k flickering because of not enough memory for double buffering (which I might find ways to solve, especially in cartidge versions). And you will notice a lot of artifacts because of the optimizations (false positive interpolations, ugly junk in fade algorithm on rpg version) bad aliasing and colors/textures which can be better.
To give the credits due, the wall and door on rpg version is from sigh, the knife I just ripped from wolfenstein 3d, the old red walls must be from art studio tile editor.
Maybe I'll write some more info on my blog or post progress on youtube when I get back to this project again (which I am not sure when, but as I was recompiling code to prepare these previews I started getting flooded with inspiration for new gameplay and ideas how to fix some bugs, so maybe it will be soon or maybe next year :P).
Anyway, I attached the previews.
Looks pretty cool. Interested to see where you can take this.
Just amazing!
What kind of magic is this! :o
Optimus the RPG is quite impressive with the fading of colors, it's very nice!
BTW you did not mention the URL of your blog?
Quote from: roudoudou on 07:43, 06 October 16
Optimus the RPG is quite impressive with the fading of colors, it's very nice!
BTW you did not mention the URL of your blog?
Sorry, it was just mention on the readme file.
computerhermit.blogspot.com (http://computerhermit.blogspot.com)
Very nice stuff!
In my opinion, the RPG should also be with a free motion, else it's only a "dungeon master", and should be done with bitmaps for a much better rendering. The huge advantage of your engine is that you can move/rotate as you wish!
Impressive.
The RPG remembers me to the PC game "Stonekeep" which was a very, very great game. Also, no free motion, only discontinuous movements and 90° rotation. Have a look at YouTube. But with a great atmosphere (sounds and grafix) and nice gameplay for that time.
On the CPC RPG is faster, so might be residual cpu power for opponents AI and sound?
Quote from: Targhan on 18:11, 06 October 16
In my opinion, the RPG should also be with a free motion, else it's only a "dungeon master", and should be done with bitmaps for a much better rendering. The huge advantage of your engine is that you can move/rotate as you wish!
That's a good point, I'll think about it, I just found it much easier now in this version to hide all bugs in the engine which normally appear at specific angles and when you walk close to some walls :)
I remember the initial video a few years back. The videos are quite Legend of Valour esque.
I think 5fps is fine on the CPC in an RPG view - I would like smooth movement from one tile to the next, but keeping the player centred definitely will remove the near-wall issues.
I guess in the free-movement version, some form of keeping the player from the wall could be implemented too?
I guess the cart version can have a better palette and fades?
Quote from: Sykobee (Briggsy) on 14:01, 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 :)
Quote from: Sykobee (Briggsy) on 14:01, 07 October 16
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.
How much memory does the basic 64 version use?
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!
How much is there left to play with , using the engine?
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
Quote from: Puresox on 18:28, 07 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
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.
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 :-)
Quote from: Sykobee (Briggsy) on 16: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 :-)
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.