globe
-
Posts
101 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Everything posted by globe
-
XXL probably meant something like Capture the flag walls, it's not a raycaster but it has thin walls and despite the grid being only 16x16, the maze can be pretty complicated because of it. With standard 1 grid square thick walls maze would be much simpler. Not that I know off, but modifying normal raycasting routine for this shouldn't be very complicated. Map data would need to change though, also texture data if you want to have more than 3. For example we could use bit pairs for 4 walls of a grid square. 00 = no wall, 01 - 11 = texture 1 - 3 Starting from North, going clockwise 00 01 01 01 would get you 'U' shaped 'room' the size of one grid square, all walls using texture 1. Ray going North East would filter the South walls with AND #%00001100 when going North / up them map, and West walls with AND #%00000011 when going East. Since raycaster detects 'leading edge' of the wall for this to work properly from all angles, adjacent squares would have to have walls 'touching' the walls of our 'U' tile. So tile to the left would need East wall, tile under North wall etc... This would also allow for different textures when looking from the inside and from the outside.
-
8 units (player moves over 32x32 grid squares), in Final Assault I didn't check corners at all so you could grind your face right against the wall if you came from the side without triggering the 8 units distance check. In 128KB engine this is fixed.
-
LUT is 5KB. Multiplier is in 1-255 range, multiplicand is always the same 20 values ( cos(angle) part, with angle ranging from 0 to 28.125 in 1.40625 increments)
-
Never really did any calculations but wouldn't bit operations needed for 4 pixels gr.7 or 8 pixels gr.8 cause a relatively big slowdown? Or is there some clever trick around that?
-
Sure that would save few KB but how fast is it? Simple lookup is constant 12 cycles. There are 40 multiplications needed for the fish eye correction ( corrected_distance = ray_length * cos (angle) ) for one frame. At 25fps that's 1000 multiplications / sec = 12000 cycles = roughly 1/3 of PAL frame spent on multiplication every second. I checked some fast routines on codebase64.org (they have routines using Quarter square LUTs too) and the ones with listed speeds spent average 70 - 100 cycles per multiplication. Now add some cycles for fixing the decimal point and we're easily down 2 or 3 frames.
-
Thanks for the report, it was a small update so I didn't test properly and there was a bug in increase/decrease turn rate controls when those were mapped to controller other than keyboard. Fixed xex in post above. Also thanks for testing, I'm glad the changes in controls worked as intended.
-
LUT lookup, as it's fastest even if it eats up RAM. Textured tunnel with speed changes wouldn't take a lot of work, floor would be a problem, proper rotating floor would slow things down a lot, skyline shouldn't be much of a problem. Besides the floor the the main trouble is that walls are always in a square grid so the curves would look 'blocky'. Ok, I'll change 'Turn speed' button to 'Speed' button and it will affect both turning speed and movement speed. For starters let's try walking speed 4 and running 8 and see haw that goes. Fast turning was going to be user adjustable anyway so players can pick what works for them. Edit: Attached version now has working SPEED button and adjustable turn rate (tied to same controls as before, so MAP = increase turn rate = 'space' in 1st preset and USE = decrease turn rate = 'z') Whole 360 degrees turn has 128 steps so any higher turn rate will look very jerky. Later when Options screen is done there will be extra options for high rate/snap turning so it's easier to use. Edit2: Bug in xex 128KB v17 fixed.xex
-
Wrong question I guess, what I wanted to ask is how many tiles do you check till you stop? When I was considering what kind of map to use for Final Assault I ended up with the map cut into smaller segments because it made the map lookup faster and enemy and item handling much easier (only active segment was handled 4 enemies max / 4 items max, rest was 'frozen' till player got there). I have no clear idea how I'd handle that on one giant map. Nice optimization, looking at the tiles that get hit twice or more times, this could save a plenty of cycles. Here's the adjustable step length version. Increasing and decreasing are tied to currently unused controls for USE and MAP. MAP = increase step length ( 'space' in first controls preset) USE = decrease step length ( 'z' in first controls preset) For strafing I subtract 2 for a slower movement sideways. Upper limit is 64 but that's basically skipping 2 map tiles in one step. To me it looks like anything bigger than 8 is too fast. 128KB v16 movement speed controls.xex
-
Thank you. Your engine looks great! Colors make it easy to distinguish between 'face' walls and side walls. Map size is really impressive and also the speed when handling big open spaces (so far I'm still stuck with 16 x 16 tiles map segments connected into bigger map, though I have couple of ideas how to make bigger maps without slowing down the raycaster too much) Do you use some length limit for rays so there's not a big slowdown with open spaces? Also the door handling is great. Doors and half height walls are on my to do list, didn't manage to cram them into 64KB engine but they will be in 128KB version. If you don't mind me asking, why 31 bytes horizontally, why not 32?
-
Shift + console keys are good, they can be all pressed simultaneously, detected individually and combined with 'normal' keys. FA already used console keys + shift for controls and this engine does too. Control is more of a problem since it can't be detected on it's own only with other key pressed. Keyboard controls are not impossible, players just have to pick the keys carefully so the controls triggered simultaneously would work. Thanks, I'll look into it.
-
Got my hands on ST mouse so I'm going to try this: https://atariwiki.org/wiki/Wiki.jsp?page=Ironman Atari#section-Ironman+Atari-UsingTheMouse Looks simple and fast, runs in VBI, no idea whether it will be suitable for looking around but I'll find out sooner or later (too many things I want to test are waiting already and there's too little free time) In emulator I prefer keyboard. Too bad there's 1 key press limit for most of it on real HW. Joystick isn't very well suited for this, but gamepad is a nice compromise once you get used to it, plenty of buttons and almost no limits for simultaneous button presses. I game both on PC and consoles so it didn't take me that long to adapt.
-
Currently walking speed is at '6' meaning you need roughly 5 steps to make it across one map tile (one tile = 32x32 points player can stand on). Strafing uses speed 4. I'll make some user-adjustable version for testing over the weekend. Well, you can always glue 2 SNACKs together The big one 64x32 is there to solve this: Once you get close enough that few rays hit the same wall slice the texture gets stretched horizontally like this and it's not pretty. Compared to new engine: Nice fat pixels without the stretched line patterns. The half sized and quarter sized textures should make the texture easier to recognize when walls are farther and wall slices are smaller. Works better for some textures, worse for others, any finer details tend to vanish pretty fast anyway because of the low resolution. It's not really complicated since the appropriate textures are picked by unrolled drawing routine (which is gigantic now, 10,5KB compared to 4 pages Final Assault used) Bank 3 is full of LUTs for raycaster. Bank 2 is 30% full - there's Controls setup and I plan to stick whole Options + main screen etc.. there Bank 1 and 0 are currently empty but this is far from finished.
-
For now try this out, movement is roughly twice as fast. Toggling is possible but I'd like to keep the number of buttons to necessary minimum because there's so many of them already. Binding running together with fast turning might work. I'll do some testing once I have Settings done. This version uses 4 'zoom levels' 32x32 = standard size, 64x32 = large size and 16x16 half size together with 8x8 quarter size for smaller wall slices In this map fps may wary between 23 - 33, but the change isn't very abrupt so it's not noticeable I guess. Also not that many people face-surf the walls which is the only way to get 30+ fps So in the end we're jumping around +/-3 frames most of the time. (all of this applies to 'full pixels', add +5 frames for black lines mode) Your comment made me curious, so I tried worse case scenario: empty map with walls only along the outer borders, standing in a corner, looking towards the corner across the map. Got 20fps which was a nice surprise for me, my guess was it's going to be somewhere around 15. Thanks. It's much easier with so much extra memory. 128KB v16 faster movement.xex
-
Yes, movement needs some rework too. Not sure yet whether it'll be just faster walking or walking + running.
-
Yes, it's player's angle but I left it in hexadecimal for convenience. Whole 360 degree turn = 128 steps so ANG goes from $00 to $7F. $00 facing north $20 - east $40 - south, $60 - west
-
Just a memory issue, nothing else. There's some fluctuation with FPS depending on where you stand. Wider open ares will go down to 23 while sticking your face closest to the wall will get you 33. Raycasting part has a lot less work in the later scenario so it finishes fast. Weapon animation shouldn't really affect the frame rate so it's probably the lighting processing that does that. Yeah, it's easy to forget this when most of the time I spend in WUDSN + Altirra. XEX that loads from $2000 is in post #5
-
Looks like I need to read up on various memory upgrades and adjust the bank switching. Well, try to set Altirra to settings MrFish mentioned in his post above yours. I'll look into the various memory upgrades and try to come up with something that will work for everyone. EDIT: Glad you managed to make it work even if it took a while. Finally something that's easy to explain:) Demo only does PAL/NTSC detection at the beginning so if you switch to PAL while it's running, it still counts 60 frames as 1 second instead of 50 and the FPS counter is bloated. Yes, both need 128KB, the only difference is the second file starts loading from higher memory address so it shouldn't overwrite DOS.
-
If you don't mind, post your Altirra.ini files, and I'll try to check what's different. Mine's attached but can't be used without some changes because of settings like this: "Kernel path" = "D:\\work\\atari\\wudsn\\Tools\\EMU\\Altirra\\ATARIXL.ROM" that would require editing the path so it points where your Altirra is installed. Tried to run both XEX files in A800Win+ and they work so there must be some config issue. Globe Altirra.ini
-
With RAM to spare I just reused the abandoned code from FA. 5KB LUT but walls aren't buckling so worth it.
-
I get the first XEX loading low won't work, but no idea why the 'fixed' one starting at $2000 won't, hard to debug when it works here. I'll try to make one more xex starting even higher when I have time.
-
Try ALT+B or through menu File -> Boot Image and pick the XEX (xex switches off Basic, no need to do it manually) I have Altirra set to PAL 130XE with firmware ATARI XL/XE OS ver.2
-
That's strange. What device did you use for loading? I tested with AVG cart and SIDE3 and both worked on stock 130XE.
-
I don't have U1M yet so I can't test on real HW, but I read couple of posts mentioning XEX files loading too low getting 'memory conflict' error (this one starts loading from $0f00) so I rearranged some stuff and now it's loading from $2000. Let's see if that helps. mem conflict v16.xex
-
Finally got some time this weekend to finish the preview for 128KB raycaster engine. features: -resolution: 80x48 -fish eye correction -proper wall slice scaling -fully adjustable controls -reworked weapons with (very) short animations 1. pick one of control presets or define custom controls 2. press ESC for 'game' (there's no game yet but you can walk around, switch weapons and shoot) 3. press START+SELECT+OPTION to switch between 'full' pixels and 'every other line is black' mode (there's roughly +5 fps gain with the later) 4. press START+SELECT+OPTION+some key to get back to Controls setup screen This is early work in progress so a lot of stuff just isn't there yet. It's both a preview and new controls test so if you find something not working properly as far as controls are concerned let me know. One feature that is missing is Settings screen so for now the fast turning has fixed speed, but in later versions it will be user-adjustable, also it will be possible to set fast turning as default. Other features in Setting screen will include weapon bobbing toggle, cross hair toggle, floor/ceiling presets + customization and more. Globe/GMG ps: It's probably clear from the title but the .XEX will only work on Atari 130XE and compatible with 128KB RAM or more. eng128 v16.xex
- 84 replies
-
- 31
-
-
-
Definitely. All the available buttons make a difference. If for some reason FA 1.2 happens I'll consider it. Don't worry, after all the work I'm going to milk it for a while :):):) I still want to make a big game that will be similar to System Shock with several floors, player augments, computer hacking, progress saving etc... But that's far into the future. Currently focusing on 128KB engine, hopefully I'll have something to show in a couple of weeks. As far as controls are concerned I added some options to 128KB engine and support for multiple controllers, but I'm kind of torn on the mouse controls. Since this kind of engine doesn't support looking up and down (well, it's technically possible to fake but not sure the cost is worth it for mostly cosmetic feature) it would be limited to turning and shooting. Also I vaguely remember reading somewhere that you have to mod your mouse for the RMB to work. WSAD controls are possible as long as you don't want to strafe while also moving forward or backward - keyboard limitations. Here's a peek of what's coming: There are a few control presets for various controllers + Custom preset that player can freely edit. Currently supported controllers: Joystick, Joy2B+ with one or two extra buttons, SNACK in Classic or Enhanced mode, Atari Video Touch Pad (+similar) keypads and most of the keyboard.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord