globe

Controls will be subjected to more testing and there will be definitely some Options screen for as much customization as possible. One thing I don't want to happen. Filling half the keyboard with various specialized controls because I don't want to force players to learn to play organ just to be able to do something in game. Simple is best (as much as conditions allow). Thank you, I'll look into it. Especially the smaller depacker without temp is something valuable for me, though I really like ease of use of deflate, easy packing with 7zip and couple of batches. Yeah. 8bit game - 8bit difficulty level:) no quick saves, no initial hand holding with interactive tutorials (there would be if I could cram it in;_;) Criticize ahead. It's clear to see that visual fidelity improvement would help a lot in the game play department too.

Thanks for giving this a thought. Looks like darker floor is going to win this as for dithering or no dithering, this time I'll probably choose clarity above looks. I'll wait for a bit more if anyone else wants to put his 2 cents in, or some other bugs crop up before I'll start with v1.1.

Yes it would, but since I didn't manage to overcome the PMG limits 'bfg' was born. Difference between BFG and bfg is explained in the info part of main menu:)

Well for these kind of controls there's very little I can do with just one joystick. Even if it was Joy2B+ you'd still have to occasionally let it go and mess with keyboard. Irgendwer offered one possible solution in post #24, SNES gamepad with shoulder buttons for strafing and enough additional buttons for everything else. There's also the gamepad I used that uses both joystick connectors for simplicity (info in EXTRA folder of game package) As for the various quick turn options, these require further testing so it's hard to tell right now what may work and what won't. Not the only way it could work but one of the instances where precision was sacrificed. Even if this was not meant for me I must say, don't worry about it. Heaven/TQA is all business all the time and I too had to ask and clarify some of the lingo. In short he said that whole floor is same color so the drawing is faster. When you only load color once and then store it as many times as required it's faster than load color / store color / load color / store color .....repeat for whole floor, but the later is necessary for the faked lighting effects so as usual it's all about trade offs.

I already addressed faster turning in post #134 (no idea how to link, sorry) to a degree but I think couple of more details are worth mentioning: First, the controls. Joystick is far from ideal for this kind of game. I used gamepad that was plugged into both joystick ports when testing on real hw but for majority of players going with one hand on joystick and other on keyboard, adding more and more controls is less than perfect. For the future Goldy suggested mixing the controls up a bit. Using joystick for forward / backward and strafe left / strafe right while having turning left and right on the keyboard near the Shift which would be used for faster turning (this would also overcome the one keypress at a time limit because Shift is handled kind of independently) . I think this is worth a try. Other thing is that fast turning has downsides too. Earlier builds used twice as fast turning (128 steps for 360 degree turn instead of current 256 steps) which was ok when enemies were close and big. When they were small and far away though it often happened that crosshair jumped over the enemy even if one tried to turn cautiously and player had to compensate with strafing. For 90 degrees fast turning there was also a bit of confusion because players FoV is roughly 56 degrees and when you turn sideways in one keystroke you see completely different view.

For big RAM version I'd consider mipmapping because the scaling algorithm this engine uses is kind of crude and the small resolution doesn't help either. Filtering would likely kill the framerate, at least I'm not aware of some neat and really fast trick.

I see couple of downsides compared to DOOM from ZX-Spectrum. Sinclair has color attributes allowing to paint the mountains in different color compared to walls while in this engine and this mode everything would be same color - blending more together. Of course something like thick black borders on the top of wall would be possible to make it clear where skyline begins but I don't think it would look especially good in this blocky resolution. Textures are going to get an overhaul because like you and others in this thread suggested, it looks like that using simpler ones and ones with specific patterns would allow for easier orientation. Guess that's one downside of this approach when 'broader public' doesn't get to see preview and can't suggest improvements early and things just get accepted as good enough. Anyway, after looking over the earlier posts I found one mistake in couple of them - big pixels in this mode are made using Vscroll trick, not Hscroll trick. Also I rummaged in the heap of 'leftover' files from development and found old intro (xex - probably will only work in emulators again) and 2nd newer intro (just a bunch of small pictures that were supposed to accompany the background story together with small PMG animations) which didn't make it for the same reason as all the other features, but since these were made and I have no farther use for them I decided I might as well post them. old intro 1.xex

Forgot to say: Thanks for all the floor testing / fixing attempts. In v1.1 floor will be definitely darker and I'll wait a bit more for people to decide on dithering etc...

Would be a lot more blocky, don't think it would be pretty. Actually having a left-right scrolling skyline, mountains or something similar for outside areas is relatively simple and computationally cheap. All you need is a mountain graphics that wraps around, that gets drawn in instead of the ceiling and a bit above. For coarse (2 pixels at a time) scrolling you need one picture, for smooth scrolling you'd need 2, one of them pre-shifted by half the byte. Or you could do a bit of a hybrid drawing and use hardware scrolling for part of the mountain that doesn't overlap with top of the walls. BTW. it was done in ZX-Spectrum DOOM If you mean the map segment with label 'High security area' with 4 keycard terminals than probably yes, honestly I don't remember, might have been that I just wanted to use all the colors we have. Yes. Rotating floor + ceiling absolutely, skyline would just eat up more RAM for the graphics.

I think it would likely run in SPF not in FPS at those resolutions but there's still Rapidus I guess.

Noted. Floor and ceiling pattern limit is 1 byte width = 2 pixels, meaning floor is made from 40 identical vertical stripes defined by the tables I mentioned earlier. I attached a cheat table you can load into ALTIRA so you can play with the patterns yourself: 1. Get in game first !!! don't load the table in intro or main menu or it will overwrite something it shouldn't and things will break !!! 2. In ALTIRRA menu select Cheat -> Cheater and in the small window that appears press [Load] button in lower left and pick the cheat table included in this post. It should look like this if everything was done correctly: 3. Top address $91E8 = closest to the player, bottom address $91F7 = farthest from the player You can change the values for each line either through double clicking or [Edit] button under the table. As for values, $FF = brightest white, $00 = black, everything in between are shades of grey. If you wanted to make a chessboard pattern for example (looks awful btw.) you can enter $F0, $0F, $F0, $0F ... till the end. 4. Last but not least, the changes won't appear immediately as you press [OK], you have to shoot RPG or bfg to trigger the full floor update (if you shoot first 3 weapons only few lines closest to player, not whole floor column will be updated). Have fun. floor adjustment cheat table for ALTIRRA.atcheats

Yes. mainly for hscroll trick (making the Gr.9 pixels vertically thicker without the need for copying same line in Display list) and for coloring and repositioning Players and Missiles. Players only need repositioning because they are also used in lower part of HUD for selected weapon coloring. Missiles are used in multiple ways. In the middle of screen for weapon cross hairs, shooting effects on the wall when you use first 3 guns, flying projectiles when you (or the last boss) uses bigger guns and in the lower half for coloring the big blocky gun shape. If this engine had the option for looking up and down it would be easy to multiplex PMGs with 2 enemies above each other - never overlapping. Can't imagine multiplexing for enemies standing side by side without annoying flicker.

XEX with half bright dithered floor attached, as always only works in emulator, not on the real HW. This one actually looks pretty decent I think. If you mean only really dark textures, there would be loss of detail since we only have 16 shades to work with. If you mean actual (even if faked) local lightning that wouldn't work at all in current engine because the lightning effect of shooting and rpg / bfg are depth only. There's no code for any local fake lighting and although we talked about level with flashlight nothing besides a few brief notes for future research exists. Currently sliding doors are possible to do but only inside the map segment (some extra ram would be required obviously), between segments it would require much more ram, rewrite of enemy handling and some clever solution (probably through level design and enemy/item placement) because of the enemy and item limit. Since 2 PMGs are used for every object and enemy, only 2 at once can be shown. Also with either kind of door there would be some slight speed penalty in the raycasting part because instead of 2 possible outcomes - we hit the wall / we didn't hit the wall, the door hit part would have to be also handled. That should be possible to fake but there won't be the freedom of movement same as in Vector engine because that one is real 3D, not 2.5D like wolf clones. My ''original'' idea from before I even started to write the code was that I'd like to make a game similar to System Shock in some ways. Like player would find logs on computer terminals with hints for door keypad codes, hack doors and mainframes (some logical mini game) etc., so nothing really groundbreaking or original but with a bit more variety than just shooting everything that moves. But after things started to materialize and RAM started to vanish really fast I realized that for this version it's not meant to be, so maybe sometimes in the future. FA FLOOR TEST 2 !!! WON'T RUN ON NORMAL HW ONLY IN EMULATOR !!!.xex

Let's hope one of these days NRV will find enough free time to finish Project-M because that 256 colors IRQ driven magic engine is in a class of its own.

Marco already suggested faster turning during the testing and we had test versions with extra controls for 12 degrees coarse scrolling (4 times faster than normal turning) and 90 degrees turns but in the end these were left out. So yeah, now the gameplay is more 'tactical', slower instead of the usual run and gun many FPSes have. Option screen is definitely something that will happen in version for larger memory machines. There's a bit of a HW problem with ATARI keys though, only one key press at a time is registered so things like 'standard' AWSD controls often used on PCs won't allow for simultaneous walking forward/backwards while also strafing for example. There are some possibilities to work around this by using SHIFT, console keys etc. but all in all it's somewhat less straightforward than what people are accustomed to from newer systems. Map toggling was a bigger back and forth between me and Marco. At first the map was toggled by OPTION, which I didn't see as a problem because I did 99% of work on PC through WUDSN + Altirra combo and default key mappings were F4 = OPTION and F5 = RESET. On standard PC keyboard there's a gap between F4 and F5 so I never fumbled around and accidentally pushed reset when turning on the map. Marco found out on real HW that it's a problem and there's a real possibility of reseting during frequent use of the map, so we moved the map key to space. As for the hold to show / turn on/off, once again I had trouble to find space. Not going to go into much details but the result was space on / space off controls needed 57 bytes and hold space only 19 bytes. This was also somewhat caused by the fact ROM was off and I had to deal with all the key pressing controls myself. Ok, noted in the v1.1 buglist. Texture generator for more variety was considered but as with many other features it didn't get in. Work in progress version is attached. !!! XEX will only work in emulators again. !!! Press Start, Select or Option to see a couple of generated textures. Compared to 512 bytes needed for one directly stored texture, 8 of these generated textures only required 582 bytes total, although many of them have simpler look without gradients and details. Oh my God! The pixels are almost as huge as the wall sockets. texture generator 2.xex

Floor and ceiling gradients are just 2 small, 16 bytes long tables, so as long as it's just editing in different values and trying out how it will look in emulator that's easy to do. Changed the floor so there isn't dithering and made it much darker because earlier someone already suggested that bigger contrast would be beneficial. For the adventurous folk that wants to experiment with own changes by editing things in emulator BASECE starts at $90F0 and BASEFL at $91E8 !!! Warning, the included XEX won't work on normal HW, it's just the game without intro, without packing and other necessities so try it out in ALTIRRA or other emu !!! Thanks for the tips. To be honest the UPPERCASE part didn't really cross my mind, so if worst thing happens and I'll need 208bytes, I'll sacrifice the little ones for greater good. As for the horizontal mirroring, I get the part about half the vram, half the texture space needed (not entirely aboard with texture being mirrored but 1 page per texture instead of 2 is surely enticing) but I don't get the 'calculation time' unless you mean time spent drawing into only half the vram. FA FLOOR TEST - !!! WON'T RUN ON NORMAL HW ONLY IN EMULATOR !!!.xex

Technically yes, it was covered in the tutorial and wouldn't be that hard to do, even a bit of faked looking up and down would be possible. It's one of the things in my big 'I'd like to have this feature in later versions' list which we started to fill as more and more things got cut. One more thing, I'm really grateful for your enthusiastic support, for YouTube vids you made and your input but if it's possible (and I'd like to ask this from the other side of the debate too) tone it down a bit. Let's just agree to disagree and realize that compromises were made, and my priorities won't align 100% with those of other people, no matter the result. I'll try to make more people happy when the version eating up more memory happens.

Gr.9 + hscroll trick for bigger pixels while vram requirements stay small. Fish eye correction was there (in earlier builds) but I decided that 5KB+ (multiplication lookup table + small routine doing the lookup and writing corrected length value into raycaster length buffer) would be better spent elsewhere. Whether drop in fps would be tolerable is debatable, 38 extra multiplications without lookup for each frame is not a trivial matter and I think we can all agree it would take much more cycles than previous memory-hungry but really fast solution. But that's not the main problem. I already mentioned several times about the RAM trouble and in the end I really had to fight for each byte, spending a lot of time during the final debug trying to get couple of extra bytes so I can fix what was still broken. So 'you can fix this easily with some math' is not that easy when you realize you don't even have space for storing 19 multipliers needed for the fisheye. Bit more details about the RAM usage: As soon as the game is started from the main menu and the DEPACKING with some siren noises takes place, the whole memory from $0000 to $FFFF (with exception of 2KB of HW registers and 6 bytes right at the end) is used. Rom is turned off (that already happens in intro) Whole zero page, roughly 2/3 of it is 'single use' populated with permanent variables while the rest is used as buffers for rendering and other non-persistent stuff that needed a boost (mostly distance calculations, enemy line of sight checking etc...) Stack from $0100 to $01bf , followed by safety gap and actual return addresses from JSRs. From $0200 to $BFFF - code and data, there are some small gaps in some of the data (enemy and object PMG graphics data aligned for easier and faster handling) but most of these gaps were filled either with small tables or with multitude of memory variables. Remaining gaps are spread through several KB of data, non consecutive, mostly small chunks (1 - 4 bytes) which makes them really hard to use for anything. $C000 - $FFFF (minus HW regs and vectors) is used for VRAM (double buffered), PMG memory (double buffered) and a whole lot of tables precalculated at runtime (biggest being 4KB for light effect LUT) or used for current running game (enemy / items / objects - positions, states and behavior) So once again, and hopefully last time, there really isn't much space for anything and a dread the moment someone finds some serious bug that would require more than a byte or two to fix. It's THAT bad.

That's the plan. If by tmapping the slices you mean scaling and drawing then yes, also lightning pass uses unrolled code (didn't manage to do scaling+drawing and lighting in one pass, not enough registers) Then there's raycaster itself, while it's not really unrolled code, for speed and simplicity reasons there's code for each quadrant + a lookup table. But the main culprit as far as the RAM consumption goes isn't really the raycasting engine, it's the game itself: Map (both the game map with walls+textures+doors etc.. and the automap which eats about 2,5KB of vram and buffers + some extra for code to generate and show it) Textures + the code for generating the animated ones on the fly because there's just no space for storing animations in RAM. Enemy graphics, horizontally pre-scaled so I don't have to waste too much cycles there. Enemy/item data for new game + the same empty table for the ongoing game. Enemy behavior code (including line of sight checking which is probably bigger than all relatively simple movement routines together) Sound effects. Text messages. GAME OVER + YOU WON parts Lots of tables of various sizes for everything else. Most of these you won't need for an engine demo so I can understand you wondering where did all the RAM go but with all that's needed for a game it ads up really fast. Well, I don't really mind the questions and things people notice. I did take shortcuts and I did sacrifice graphic fidelity and precision for speed and other features. I can understand that some would prefer to balance things differently but this is the result and, well, there's plenty of people here commenting that could pull off making their own version so maybe this game will motivate someone to do better and we all get more games to play on our favorite hardware. Also I don't consider this 'hammering', so far the discussion was very civil.

Hopefully. I have couple of ideas on paper that could speed things up and make them look a bit nicer too. But it will take time and there are other works in the pipeline too so don't hold your breath.

I'd guess there are 2 main reasons for things going a bit wonky. I sacrificed precision for speed and threw out fish eye correction routine with it's 5KB large lookup table when Ram got extra tight. Another reason might be that there's relatively low number of vertical sizes for wall slices so even when the slice goes farther or closer just a little bit, it's not really visible.

Hold Start+Select+Option !!! these need to be pressed during first depacking, before 'GMG production' screen starts to appear !!! No. Sound effects are done through normal 4 channels and the clicking of proximity detector is done through writes into CONSOL / $D01F

Not sure what 'clamping' means in this context but yeah, there's 4KB lookup table for the lighting effects. Tried it out, looked 'interesting', you could play chess on the pixels if you wanted:) but in the end it looked better on small 10'' LCD.

No need to tiptoe around the issue, the pixels are huge and often it takes time to look around so one can realize how immediate surroundings actually look. Automap helps a lot in this regard though I wish I could use bigger resolution for more details there. Well, current engine uses hscroll trick to make the pixels so more detailed weapons are impossible. Maybe half height pixels for later versions with larger RAM use would do the trick. As for the floor / ceiling coloring, with current graphic mode I have no idea how that could work so maybe I'll try using bigger contrast compared to walls so they don't blend together. Definitely. Having something like Pulse rifle sounds form Aliens would be absolutely awesome (well, besides the inevitable lawsuit;) Goldy already suggested it, and it would be definitely useful but there was no space. (I am using the self imposed memory limit as an excuse a lot, aren't I?)

That's ok. Game's already done and if someone wants to bump the thread for weeks, who am I to stop them:) Very few bytes free, but I checked the controller and there's plenty of buttons (including shoulder buttons for strafing I very much prefer) so it is theoretically possible. In thread you linked, you wrote: When switching to the enhanced mode (with SELECT + START + R (shoulder button) ), all buttons are mapped to a single controller port, in a quite clever but also easy to use way So how does the button encoding works? Are there any limitations for multiple button presses? (is it possible to move forward, while also turning, strafing and shooting all at once?)