Looks like someones started work on this ...
;D
??? Is this realtime? Sorry for the question, but I didn't quite understand the description given on youtube.
Not totaly in fact , only the renderer is real time , the raycasting is precalculated
Executioner (WinApe author) worked on one too (http://www.winape.net/downloads.jsp)...
Actually Optimus gave some more info on the forum that he first upload it
but i believe he'll come around here to give some more info
about his new (game wanna be) creation
@optimus
εξαιρετικη δουλεια optimus ευχαριστουμε!!!
.
Quote from: spybro on 23:21, 30 December 10
Actually Optimus gave some more info on the forum that he first upload it
but i believe he'll come around here to give some more info
about his new (game wanna be) creation
Great ! i can not wait !
Reminds me of the time I played Doom on my mates 386SX... we had to reduce the size of the window from full sceen to something like you see in that demo, still playable mind. What impresses me the most is how smooth everything runs.
I will be amazed the day it will be interactive ;D
This. Is. Incredibly. SMOOTH.
Hello and happy new year!
In this video I started with the fastest column renderer I could think of.
There is also an untexture version that is 1VBL. The texture version is running at 2VBL because of vsync but is less than this, around 1.3 and 1.6VBLs depending on the wall sizes. This means there is some more raster lines to spend here for the raycasting. If I am lucky it will be 3VBLs with a realtime raycasting engine, else no more than 4.
I have thinking hard on the maths for CPC, I have precalculated some tan tables and dist tables that will help me with most of the stepping and getting the distance with simple additions of 16bit regs as 8:8 fixed point. But there is a single initial step where I might have to make an 24bit mul. That means 64 times a mul per frame. Then from the distance finding the wall height to render, either a division or maybe some weird precalcs. And how about the fishbowl distortion fix? I haven't thought of this yet. Zooming sprites for the future will be another challenge. Not as fast as column renderer, different routine needed, also I'll need some more maths to find which sprites are in the view of the player and project their real position to screen positions plus a zooming factor to know how to zoom depending on the distance. Of course I haven't thought of this part yet. But I have thought of the raycaster and most of it might be just adds of precalced luts. I am about to write it but I was busy with some real life stuff recently. I think I will have my next preview of a working true raycaster on January or February.
My initial inspiration for my project was this one on AtariXL
http://www.youtube.com/watch?v=DuZywAxfGkw (http://www.youtube.com/watch?v=DuZywAxfGkw)
I was inspired to use half scanlines rendering from this video.
Then I have byte rendering (two mode0 pixels width of column, it would be quite slower with per pixel rendering), 64 bytes on width (64bytes screen width mode too), 64 scanlines on Y (128 screen height). These were choosen instinctly. And then I realized that I have choosen exactly the same screen setup as the AtariXL demo :)))
Even the textures are 32*32 both in my case and that video. I am curious to finish the raycasting so that I can compare the speed.
Also, this is mainly going to a game project. I am a bit fed up with demos, I think games are more interesting to programm. And challenging. I'd like to answer the question, could a game with such technical engine be made on CPC? Generally speaking, I want to code something else on CPC (game, app, whatever), also something else than demos, there is a new field for me there and I am also fed up doing demos for 10 people. This engine was appreciated more from people who are not necessarily into demos but might be retro gamers or just curious about tech in 8bit. And this is motivating. Not that I will quit from demos. We still have to finish a big one and then I will see and decide if I will continue doing this..
I noticed in the atari demo that it is using 64k. Are you making this for 64k or 128k?
edit: I started thinking about Mirrors Edge ;D
Quote from: Optimus on 12:23, 03 January 11
Also, this is mainly going to a game project. I am a bit fed up with demos, I think games are more interesting to programm. And challenging.
I think that demos are generally machine specific, where as if you program something technically challenging then the whole 8-bit/retro scene gets interested (especially if it's a game!).
Great work so far, and will watch with keen interest as to how it develops.
QuoteAlso, this is mainly going to a game project. I am a bit fed up with demos, I think games are more interesting to programm. And challenging.
The way to go! ;)
@sigh: I am always working for a 128k machine. The engine still have space to work on 64k but it will be too much when it turns out as a game. I spend 32k for double buffered vram (well, maybe less since I am at 64 byte width mode and don't use all scanlines yet), almost 8kb for the renderer, 8kb will fit 8 32*32 textures, some space for code. I plan to have some maps, the sprites, more textures. I will move to 128k definitely.
Quote from: Optimus on 12:23, 03 January 11
Also, this is mainly going to a game project. I am a bit fed up with demos, I think games are more interesting to programm. And challenging. I'd like to answer the question, could a game with such technical engine be made on CPC? Generally speaking, I want to code something else on CPC (game, app, whatever), also something else than demos, there is a new field for me there and I am also fed up doing demos for 10 people. This engine was appreciated more from people who are not necessarily into demos but might be retro gamers or just curious about tech in 8bit. And this is motivating. Not that I will quit from demos. We still have to finish a big one and then I will see and decide if I will continue doing this..
I like this bit a lot.
I do like watching demos when they're posted on YouTube, but these days I do wonder how many people see them or really care. I don't know much about the 'demo scene' but I guess during the 90's it was a kind of way of showing off your skills and techniques to people on the scene, coding prowess and all that - but showing off what the CPC is capable of. I don't think it impresses as much these days as it gets to the point of 'seen it all before' made worse by being flooded with demos that consist mostly of scrolling text taking 10 minutes to thank anyone and everyone and talk rubbish! What's now impressive is seeing some of these techniques and these skills being used in games and apps - I often thought what if all these demo coders to just get together and make one amazing product....
It's nice we're beginning to see such things, like Orion Prime for example, and now hopefully Wolfenstein ;D
I don't mean any offence to any demo coders though, I think my point being is that I'm thinking of you and your skills being seen and *appreciated* by a larger audience. But demo writers - don't stop making cool demos too anyway :)
Quote from: Optimus on 00:28, 04 January 11
@sigh: I am always working for a 128k machine. The engine still have space to work on 64k but it will be too much when it turns out as a game. I spend 32k for double buffered vram (well, maybe less since I am at 64 byte width mode and don't use all scanlines yet), almost 8kb for the renderer, 8kb will fit 8 32*32 textures, some space for code. I plan to have some maps, the sprites, more textures. I will move to 128k definitely.
Welcome to cpcwiki forums Optimus and also welcome to game making!
I hope the game works out.
I think continue to develop it, put in all the required game features and mechanics and then if it's too slow, see if you can squeeze some more time out of it, or modify the game design to avoid the slow downs.
It is all good experience!
Once you've made one game, you'll find it easier to make the next because you will have your tools ready and your build scripts too.
Good luck with the ray casting algorithm - and remember to store the 64 calculated Z-depths for your sprite rendering portion (if sprite Z-depth > wall depth for any X, don't draw the sprite in that column).
And hey, if it works out slow eventually (under 10 fps) at least you have a neat engine for Dungeon Master style games with:
(a) large first-person view, not a tiny view like Bloodwych, etc.
(b) no need to manually draw all of the possible wall and floor graphics pre-rendered
My original ray casting Wolf3d demo did do the pixel rendering (half-byte) and also rendered the whole 128 scan lines rather than only 64. These are two quick optimisations which really would have improved the speed, but I didn't want to sacrifice the quality that much. It's a pity I never had the time to get back to it, 'cause there are a heap of improvements I've thought of over the last few years.
Quote from: Executioner on 12:58, 14 February 11
My original ray casting Wolf3d demo did do the pixel rendering (half-byte) and also rendered the whole 128 scan lines rather than only 64. These are two quick optimisations which really would have improved the speed, but I didn't want to sacrifice the quality that much. It's a pity I never had the time to get back to it, 'cause there are a heap of improvements I've thought of over the last few years.
Dude... screw real life, and get back to the CPC drawing board? lol
Or at least, please improve WinApe's source code editor ;)
Quote from: Optimus on 12:23, 03 January 11
...I am a bit fed up with demos, I think games are more interesting to programm. And challenging.
I do totally agree ;D 8)
Yes... it's kool to get a demo to mimic Wolf3D but a bit pointless...
Such Game cannot realistically be good nor fun nor fast and furious...
Because it is clearly not the right computer generation...
A Wolf3D like game on CPC would be some Xybots-based engine indeed.
So if it is just to be a Demo, why only limit yourself to Wolf3D look alike ? you may find more artistic design or concepts.
Quote from: MacDeath on 10:02, 15 February 11Such Game cannot realistically be good nor fun nor fast and furious...
I don't share your point , let Optimus time to finish his work ;)
Me neither, It's all about pushing the CPC to new limits!! I think what have been achieved up until now is stunning!
I am looking forward to how good a CPC version will be!..
/Ygdrazil
Quote from: fano on 12:49, 15 February 11
I don't share your point , let Optimus time to finish his work ;)
I wish I had more than a few hours a month to spend on CPC related stuff, and that I actually spent that time doing things! Also I need to commit to a project idea, and get beyond having it on paper. I'm looking forward to norecess's IDE as that will make transforming graphics, tiles, etc a lot easier, which will give me some incentive to continue with work, SDCC, Z80, etc.
Two projects on paper with a little code - a dungeon crawler with a wolf3d style engine - maybe stylised a bit to simplify graphics and factor in my currently less-than-optimal Z80 attempts (want to try that POP/PUSH/EXX/SET/RES stuff from the other thread next), and an overhead Times Of Lore style game, but full screen with surge-scrolling (via hardware) because it will look more impressive and probably be more optimal than redrawing the entire play area. Don't bet on either of these anytime soon. I will be working from home more in the future due to changes at work so I'll be squeezing in some development that way!
Quote from: Executioner on 12:58, 14 February 11
My original ray casting Wolf3d demo did do the pixel rendering (half-byte) and also rendered the whole 128 scan lines rather than only 64. These are two quick optimisations which really would have improved the speed, but I didn't want to sacrifice the quality that much. It's a pity I never had the time to get back to it, 'cause there are a heap of improvements I've thought of over the last few years.
Well, optical yours did look way better. The other one is very nice too, but the pixels are jumping around as if they would have taken an ACID or an ASIC ;) .
Compliment to both coders, but the first version still deserves the first place.
QuoteSo if it is just to be a Demo, why only limit yourself to Wolf3D look alike ? you may find more artistic design or concepts.
I don't understand this. Well, because it's impressive. Isn't this what a demo is about?QuoteSuch Game cannot realistically be good nor fun nor fast and furious...
This is something I am curious about as I will continue working on a game project with this engine. I wouldn't like it to be just a proof of concept of something technically impressive (then it WOULD make a sense for a demo but not for a game) but lack the playability. I'd still love the technical aspect of it, but could this be a good game that people would love to play?
When John Carmack from ID software wanted to make a doom franchise game on mobiles, he wasn't going like "wow, I will do doom for mobile phones and people will scream impressive" but his thought was what kind of game would be playable on mobiles. Real time fps probably not, not just because of the speed, but the controls. So he thought of the Doom RPG turn based concept with a still impressive engine. It was a good idea and it was actually quite playable. It was one of the few good mobile games I enjoyed.
So, one concept I had initially in my mind was that with a wolf3d engine it doesn't have to do wolfenstein action style. It can be a turn based maze RPG but with smoother transitions in movement, it can be other stuff too. Though, I am still thinking for my first game with this engine of a wolfenstein style realtime action. Because it's more challenging if a good game can be made with this. For mobile phones it was a no-no because of the stupid controls, but on CPC you have good controls, you only need speed. I am thinking of a hybrid action-adventure though.
Funny thing is I was talking I was fed up with demos, but there is a slight possibility I make a little demo for Forever party with this engine. In any way, the Forever deadline is a good motivation for me to speed up coding, because I will still need to finish the real time raycaster code for this demo idea (I don't want to fit another big animation), so I will also have progress with the engine for the planned game.
Anyway, with the project I spent a lot of time since my last preview to port the code from PhrozenC to SDCC and now I have a very good framework with a PC/CPC hybrid project, where I can also compile the PC project that emulates part of the CPC vram in an SDL window, so that I can write code and see results without always having to upload a binary on a dsk and starting the emulator. It totally speeds up developing! Yesterday I finally had the whole code working both on CPC and PC and it was "What you see on CPC, you see on PC" exact preview window too. Today I have finally started writting the raycasting code and hopefully I will have it working soon enough because I'd need to optimize it too for the CPC.
QuoteYesterday I finally had the whole code working both on CPC and PC and it was "What you see on CPC, you see on PC" exact preview window too.
I did that since Phat 1 days. I bet today this will become mainstream for every average CPC developer here in less than 5 years from now !
QuoteI'm looking forward to norecess's IDE as that will make transforming graphics, tiles, etc a lot easier, which will give me some incentive to continue with work, SDCC, Z80, etc.
Sure, my IDE in its current state is 20-25% of what you said :)
*BUT* it's still not ready for prime-time. By example, graphic conversions are tied to MODE 0 (which I use for my own productions). To be publicly usable, it would necessit from me implementing also MODE 1 and MODE 2.. I also use the same CRTC configuration with all my prods - opening it to something more generic would require some changes graphic-side.
Still, I see interest in releasing the IDE one day publicly, it just need to be even more mature for universal usage! :)
But back to the thread, I love the direction Optimus took with its engine. Moving to SDCC was a safe bet from him ; for his game he has now access to all the power of Ansi C - which the original Doom has been developed with. I wish him all the best, I'm sure he will succeed in something great (personal message to Optimus that also want to create a demo with its engine : if you want to improve over the existing, make your demo INTERACTIVE, cf. Moody from Vanity is all-precalculated - even if they claimed on their forums it was realtime -, go a step further by giving interactivity to the demo-watcher!).
I think some sort of street racing game would be perfect for this. One type of car/Kart/bike with different colours and replacing the brick texture with office block windows. There would be less sprite data than making a 3D shooter.
Quote from: sigh on 19:46, 20 February 11
I think some sort of street racing game would be perfect for this. One type of car/Kart/bike with different colours and replacing the brick texture with office block windows. There would be less sprite data than making a 3D shooter.
You could certainly have stacks of tyres and turn-left/right arrow signs, and thus save a little bit of time on the rendering as they would only need to stack up to eye level (whereas with the FPS they go up to ceiling level). I suspect the ray casting is going to the the time consuming part though, and an action 3D kart game really needs the FPS.
QuoteI think some sort of street racing game would be perfect for this.
Not really actually, I personally think MODE 7 technique is more adapted for racing games. Have a look at Nintendo's F-Zero (http://mo5.com/musee/jeuxvideo/images/snes/fzero/fzer10.jpg).
Perhaps the next Optimus's challenge after the raycast engine ? :)
Quote from: norecess on 20:53, 20 February 11
Not really actually, I personally think MODE 7 technique is more adapted for racing games. Have a look at Nintendo's F-Zero (http://mo5.com/musee/jeuxvideo/images/snes/fzero/fzer10.jpg (http://mo5.com/musee/jeuxvideo/images/snes/fzero/fzer10.jpg)).
Perhaps the next Optimus's challenge after the raycast engine ? :)
I see what you mean. It's slightly tilted upwards to give more view of the area on racing games. (I also didn't know that this was called mode 7.)
A first person shooter (Wolf style)or 3rd person (Vanquish style) does make better sense.
Mode7 is the standard thing for mario kart style racing. I haven't coded this routine before but I had been thinking recently how would it work on CPC. I was even thinking if I could enhance the floor/ceiling with it in the wolf3d or if I should leave it as it is. I might try it soon enough.
I never thought the wolf3d engine would go for a racing game. You mean something like indoors racing? Lol! I think now of some levels in mario kart on GameCube or Wii. Why not?
Texturing floors/ceilings is far harder as each pixel needs a ray cast, unlike the fast column rendering when you just do the walls.
However if are just going forward, and you switch to fast row rendering, you can have a racing game similar to F-Zero. However as you can see from the F-Zero screenshot it is redrawing around 2/3rds of the screen each frame at least which would be tough for an old arnold. But you don't need to ray cast - you know the distances already as you race along a 1D track with a fixed camera above it, you're not running around a 2D maze.
But how do you have a hill or a valley in the race track - well (one idea off the top of my head just now), think about ray casting fisheye - you need to divide the distance of the column by cos(angle) to correct the perspective... well, a hill would be kinda like fisheye. So you would need to divide the distance of the road by 'hillFactor' * cos(angle). A flat road has a hillFactor of 1. Increasing that creates a valley. Decreasing it creates a hill. Not a perfect hill, it's just an effect on the curvature of the road sides.
Any news on this?
QuoteMode7 is the standard thing for mario kart style racing.
mmm,not is exactly the case.Super mario kart not is made only with the mode7 of super nes.
Well,is true that uses mode 7,but it only works perfect because the cartridge of super mario kart uses de dsp-1 chip.(Math coproccesor for intensive floating point).
The mode 7 used in super mario kart,require a lot of power.Without dsp.snes can't move super mario kart.
And in f-zero,A bsx chip is used for potencier the mode 7.
Quote from: Briggsy on 19:46, 22 February 11
Texturing floors/ceilings is far harder as each pixel needs a ray cast, unlike the fast column rendering when you just do the walls.
I disagree and especially in relation to SNES mode 7.
I am fairly certain it can be done with simple interpolation for each scanline.
You only need to know the distance from the camera, and the x,y interpolation values for each line. Then you can calculate the address in the tilemap and interpolate the pixels to make each line.
Do this for every other scanline, do a byte a t a time, fill the ones in between and you're done.
It'd be blockey, but I think it could work.
Of course, no hills, but then did f-zero have this on SNES?
A new Alien-Adventure would be nice, Nostromo in 3D on CPC.
I'm still feeling a racing game despite it not being the appropriate viewing angle. Imagine the ground moving at the speed of supercycle, but the buildings/walls moving the speed that they are. This would give a fantastic illusion of distance with speed.
QuoteAny news on this?
Unfortunatelly the project is stalled at the moment. I was studying hard since two months for my master exams, which if I fail I don't get a third option. They end at the beginning of June so then I might get back to it.
So far, I have a very slow raycaster in C (lol) and another idea of an engine, with precalculation on the fly, which will work kinda faster if I optimize more and write this damn part in assembly (it's fun writting your CPC code in C and then you are too lazy to convert :) ), where the player could be at a center of a block and rotate around and then move to another center of near blocks, imagine something like eye of the beholder or bloodwych, but now the movement transition will be smooth and when you have stepped in another block you can freely look around 360 degrees but only move at angle of 90 degrees. When I realized this way, I dreamed of a cool RPG, so this will be another project. But I have to finish one first, too many things :)
The floor, I haven't considered putting one on my wolfenstein engine, but it would be nice to try. Yes, can be done with interpolation. On a straight raster line the increment step on the texture does not change. It changes on Z, moving on another raster line that is. So it's the same as rotozoomer but the increment step on each raster line is analogous to Z now (could be precalculated maybe). What I need to think is how to find an algorithm so that I render a floor that is not covered by the walls? I mean after rendering the walls, cover the empty remaining areas with the floor algorithm. Doom did this with some kind of flood fill algorithm. This could be tricky. Or would it be too much waste to do such an algorithm and faster anyway to just draw the entire floor and then the walls from above? With double buffering it won't be noticable and the area is small (64 * 64 bytes really). This could be selected from the options (among with other rendering options) if it prooves to be too slow for some players.
Good luck with the exams, mate... what field?
It is computer graphics (no problem with that :) but also imaging and vision (some really hard subjects here)
Sorry to bump this thread, but I wondering if there has been any advancements on the actual gaming elements of this amazing engine. I know that there was a demo released mid last year, but is there further work being developed on this for gaming use in 2013?
I was wondering if there were no more memory for sprites, ram could always be freed up by having the graphics in mode 2 instead.
Edit: I had accidently put mode 1!
Just saw this and wanted to comment that I've seen a few ray casting games like this on Z80 based TI calculators (warning, these videos may hurt your eyes):
A 3D TI-83+ Game: Gemini (http://www.youtube.com/watch?v=vAC4b9p7m3o#)
Elimination FPS Preview: Level 5 (http://www.youtube.com/watch?v=xa1gkN8scm8#)
Though this calculator (TI-83) has a 6MHz Z80 it only has 32Kb RAM. But it's only 1 bit colour so textures are very small! And I know; seriously, it's a calculator, why?
Quote from: Munchausen on 01:21, 11 January 13
And I know; seriously, it's a calculator, why?
Because you can.
Bryce.
Quote from: Munchausen on 01:21, 11 January 13
And I know; seriously, it's a calculator, why?
Well I know where I went wrong in my life now, I thought calculators were only good for typing rude words on :D
That's amazing! :o
I'd be interested to know the screen resolution and memory layout of this machine.Btw, the source code may be very interesting.
Quote from: Bryce on 09:48, 11 January 13
Because you can.
Bryce.
Yeah, I was just pre-empting other peoples comments. I have a switch on the side of my TI-83 that doubles the clock speed. Why? Well, I can't really justify it, so, just because. But this is insane!
All this talk reminds me of this:
(http://www.smbc-comics.com/comics/20110217.gif) (http://www.smbc-comics.com/comics/20110217.gif)
Quote from: fano on 12:20, 11 January 13
I'd be interested to know the screen resolution and memory layout of this machine.Btw, the source code may be very interesting.
TI-82, 83, 84, 85, 86 are all Z80 based and most have similar games. Some of the calcs are much more powerful though... latest version of the TI-84 is clocked at 15MHz! There is even a GB emulator. The TI-89 (though its a 68k) has a speccy emu.
For memory maps etc check out the wikiti here: [size=78%]http://wikiti.brandonw.net/index.php?title=Calculator_Documentation[/size] and ticalc.org [size=78%]http://www.ticalc.org/programming/resources/[/size]
ticalc.org is the best place to find software for these, or used to be, anyway. Source code for gemini (top video) is included in the download here: Gemini - ticalc.org (http://www.ticalc.org/archives/files/fileinfo/247/24742.html)
BTW, that video doesn't really do gemini justice. It has moving doors, enemies, weapons and full levels with a bunch of different textures.
Quote from: fano on 12:20, 11 January 13
I'd be interested to know the screen resolution and memory layout of this machine.Btw, the source code may be very interesting.
The TI-84 has a 96x64 screen.
Bryce.
Clever, amazing and impressive!
Quote from: Munchausen on 01:21, 11 January 13
Though this calculator (TI-83) has a 6MHz Z80 it only has 32Kb RAM. But it's only 1 bit colour so textures are very small! And I know; seriously, it's a calculator, why?
:o And I thought that Dungeon Master on HP48 (http://amphi-gouri.org/hp48/dm48/#presentation) was impressive for a calculator.
(http://amphi-gouri.org/hp48/dm48/dmanimated.gif) (http://amphi-gouri.org/hp48/dm48/dmpreview.gif)
The second screenshot is the actual game speed.
Quote
Core code in pure ASM (fast!)
Data formats highly optimized for low memory consumption
display of: walls, teleporter fields, buttons, on-floor objects, flying objects, stairs, carried objects, secret areas (walls you can pass through).
carry objects, pick up those you find or put them down, throw them away (they don't fall yet!). You have a backpack containing up to 18 objects and 6 pockets assigned to keys for fast access.
climb stairs up and down, fall into pits, be teleported. Unlimited number of levels (so far, two levels, and a limited width of 64, and 4096 blocks).
save the game and be able to continue later.
all 3D display with a real-time shrinking display routine, used for monsters and for the animated splash screen, like in the original Dungeon Master game on the Amiga.
More screenshots on DM48 Home Page. A Dungeon game for the HP48 (http://amphi-gouri.org/hp48/dm48/#photos) with items etc.
Game download size is 18928 bytes.
Let's compare...
HP-48 (http://en.wikipedia.org/wiki/HP-48_series) runs on a 1MHz saturn processor with 4-bit wide bus (http://en.wikipedia.org/wiki/HP_Saturn_%28microprocessor%29) with 32kb RAM total.
Resolution on HP48 is 131x64 pixels.
HP-48 was introduced in 1990, TI-83 in 1996. Perhaps it's not bad after all.
Sorry to bump this thread - but I was wondering if anything at all is happening with this?
I was watching the spectrum version of wolfenstien. Very impressive stuff!:
WOLFENSTEIN 3D game on ZX Spectrum 128!! (http://www.youtube.com/watch?v=n53-M6W2wEU#)
I know that Optimus was saying that most of the memory was used up for the raycasting and I think that the way this version on the spectrum is being handled is quite interesting. The letterbox screen and 1 colour gives a very good speed(though it's hard to make out certain objects/things). The layout of where the gun sprite is placed is also a very good idea to keep things simple, but I much would of prefered to have seen the gun on the actual play area as that would of made the immerive nature of an fps much more complete. Also in regards to the sound - I think that sound effects of footsteps, doors opening and monster type sounds would of worked far better to enhance the overall atmosphere rather than a soundtrack.
There also seems to be some sort of sprite scaling for the enemies?
I'm thinking that mode 1 graphics and a smaller screen like the speccy version (but with enough room to have the gun on the play area) would be idea for this game in terms of memory and would provide quite a smooth experience. Graphically - if everything thing could fit on an 16kb sheet, then another 8kb for sound and then leaving the rest for renderer/AI etc how feasible would this be?
First preview of my wolfenstein engine for Amstrad CPC (http://www.youtube.com/watch?v=COH55Uj53TY#)
Looking at the cpc version, it has a lovely smoothness an it's very clear to see what's going on. :)
Is this finished and in a downloadable form? if it is I would love it
The Speccy is very nice in working around the difficulties, but I think it ultimately doesn't look too good. It's ok if you know the original and have it in mind, but on its own it's quite messy...
If a Spectrum can do it a CPC definitely can