Jump to content
Search In
  • More options...
Find results that contain...
Find results in...


  • Content count

  • Joined

  • Last visited

About Optimus

  • Rank

Recent Profile Visitors

1658 profile views
  1. Optimus

    Doom ports tested on Acorn Archimedes

    The A7000+ processor has 8k unified cache (still small). It could be a cache problem since Doom is having big textures. The throughput is pretty good, I made some tests in ARM assembly, very fast memset/memcpy with LDMIA/STMIA (load/store multiple registers) tricks and in 320*256*8bpp a memset would hit a bit over 800fps and memcpy a bit over 300fps. That's pretty damn fast! p.s. Jokingly I was thinking yesterday to attempt a port of OptiDoom 3DO to the Archimedes as they both have ARM, and I could think easily of how to replace the rendering, however I am always discouraged making full ports to other machines, because I have no idea about audio, CD-Rom streaming and some other things that could come in my way.
  2. Optimus

    Doom ports tested on Acorn Archimedes

    Possibly someone could port prboom. Also, if we port Fastdoom, the video modes of archimedes are different so the rendering has to be rewritten anyway. Afterall the original ports are also ports from some original Doom port, so I assume the most algorithms haven't changed, just renderers rewritten/optimized for the machine. Btw,. these ports are not mine if it seemed so. I am just showing the two ports existing for this machine just for historical reasons.
  3. I've just made a short video showing two Doom Ports and few other relevant things (Wolfenstein 3D, FQuake demo) on my recently acquired A7000+ (ARM7500FE @ 48mhz, equipped with 40MB Ram). I thought it would be interesting as the only video showing Doom on this brand of machines is in a slower archimedes (of course if you want to go faster there are the RiscPC with StrongArm processors, but those go too fast to be interesting). I am showing two ports. One is free and I found in the programmer's site, which port is the slower one. And the other one called Doom+ is still sold by a company named R-Comp. And that's what surprised me actually, a Doom port for a retro machine still sold commercially. I bought this one out of curiosity, and it actually comes with. A 3.5" floppy disk with the port and additionally a sealed PC CD of Doom Collector's edition to copy the WADs from there. There are some interesting things in this port I am showing. I also give a sneak pic on Deth editor for Archimedes at the end. Generally, I classify this machine to be close to a low end 486 on speed. It runs Doom kinda nicely, not perfect but smooth enough to play especially in the low quality rendering. There is also mouse support and even network play which I haven't tried of course (I haven't even managed yet to connect the machine to the internet but I have an ethernet card for it and will try).
  4. Optimus

    OptiDoom, my Doom port for 3DO.

    Interestingly enough I was looking at the source codes of GBADoom and ChocolateDoom for the R_MakeSpans function like here The one that converts vertical visplane gaps to horizontal edges. I think it's a bottleneck on 3DO. I was surprised the versions in the other ports look more clean and short than the one on 3DO (the big do-while loop in DrawVisPlane) And I thought it should be slower, but looking it closer, algorithmically it seems to be doing roughly the same think as the others (comparing top bottom gaps from left to right, depending on inclination it will either mark horizontal edges or call to render a horizontal scanline) But maybe, maybe... (and I haven't tested yet by converting the other codes, I need to be careful as it's a confusing code) the 3DO version was optimized to be doing less in the inner loop. While the others (chocolate doom, etc) are doing two checks in the inner loop (e.g. while (t1 < t2 && t1<=b1)) the 3DO code has some more if blocks, which however do these checks externally and ends up with a Count, it only increases it and does one check instead of more in the final loop. So, I thought I could find something here (and I can still bother to try porting the other versions and measure (sometimes they do it with a while, sometimes with if, don't know which produces better code)) but it seems the 3DO programmer did the best to produce the optimal compiler code. I ask the compiler to display the produce ARM assembly code and man, it seems like it's pretty tight. All fit in registers, an ADD to increase, a CMP and a branch. I start wondering if there is less of a bottleneck here and more in the things happening in the later call to draw scanline (in MapPlane). Previously, when in my flat color visplane rendering I skipped this conversion and only drew vertical lines, at the same times I of course avoided the calls to MapPlane. That's also why the flat visplanes without depth shading are way faster than the shaded untextured ones. Anyway, still looking at it from time to time, at some point I'll change strategy and try to replace visplanes. But I wonder if there is a better algorithm for the conversion from vertical to horizontal edges. I kinda understand how this one works visualizing the pixels in my mind, but can't think of a better way of doing it.
  5. Just a question and a guess for optimization as I was recently trying the latest version. First I notice that when you switch to flatter surfaces, these can be sometimes slower than shaded flat surfaces. When I display the fps and looking through the zig zag floor near the acid on E1M1 for example, the flatter surfaces can be a bit slower. Now I have a guess about that. First of all,. it's a good trick that the flatter surfaces will skip the process of converting vertical visplanes to horizontal. They will directly draw vertical lines instead. But I think the loss is because you have to OUT for switching the mode-x bank each column. And maybe the horizontal renderer would switch less times than this. Not sure about how to fix this easily. I have some ideas and was trying to compile FastDoom on my PC to try things but forgot it. But I think that the same thing is happening with the potato mode. Unless I am mistaken and you have fixed this somewhere, looking at planar.asm in R_DrawColumnPotato_ there is mov edx,SC_INDEX+1: out dx,al every column. Now there might be less overhead on the potato mode as the columns are much fewer. But have you thought that in the potato mode you don't need to change banks more than once per frame? Since every pixel (even from walls, floors/ceilings/sprites/etc) is the first bank pixel scaled 4 times, you could do this OUT once in the beginning of the Doom frame and never have to do it again at least for this mode? I think potato mode could be even faster just with this change. I've just noticed that and I could have tried it myself, but since I am busy with other coding projects and you need something to work on, that could be an obvious optimization if I am right the mode-x bank switching is happening more than once per frame on potato mode, while unecessary.
  6. Optimus

    Rank Mapping Qualities in Order of Importance

    1. Atmosphere 2. Gameplay 3. Texturing 4. Map Layout 5. Geometry 6. Item Placement 7. Music 8. Difficulty 9. Map Size 10. Story
  7. Optimus

    OptiDoom, my Doom port for 3DO.

    Yes, I have already identified some parts that could be improved, I am not stuck yet without solutions but just need to motivate myself to focus studying more on these parts and get some good idea instead of fixing other parts or adding effects. The most wasteful part is with the visplanes, especially the later part where vertical edges are converted to horizontal, but I am juggling with other ideas in my mind of how to avoid the visplanes or calculate them in a more effecient way. Just need to get back into it and focus on this particular part. Is there a GBADoom source code ever released? As for GCC, I was trying to use it, others have tried in the 3DO community, there are some issues. The official 3DO API doesn't come with source code, just binaries and header files. And these binaries have different format. I could succeed compiling most C code from Doom or other 3DO projects, but fail to link. I was kinda discussing this with other coders on the 3DO and not, but not sure if there is an easy solution. I have no idea about compilers to get a guess whether there is an easy way to build with gcc and link the 3DO API or it's an enormous task. At the same time it would be an enormous task to research and rewrite low level functions for the 3DO recompiled on gcc or something. Meanwhile, looking at the code ARMCC produces, it seems quite optimized (but I would certainly want to check whether there is any gain on gcc) possibly because ARM has more register and is easier to be optimized by the compiler than X86.
  8. Optimus

    OptiDoom, my Doom port for 3DO.

    I've decided to release the next version, called v0.2b as I didn't managed to get into the bigger goals for v0.3 yet (mainly replacing the floor/ceiling visplane rendering method with something entirely different) but added a lot of new rendering features that can help with performance a bit more in exchange for quality. The old way of rendering double pixel wall columns would only go through one part of the code, but didn't work well with the first pass through wall columns used for the visplane calculation, so it didn't gave as much speed. But this method is literally rendering the game in half width/height windows and then scaling back using the CEL hardware of the 3DO capable of rendering the full framebuffer as a texture with little overhead. So there are various pixel scaler modes like 2x1, 1x2 and 2x2, a fit to screen even for tiny windows. You can kinda approximate similar configurations like the SNES, GBA, Jaguar (who all really went for the pixel double on X if you look at it, and some were missing depth lighting or floor texture) and stretch it back to full screen, and see 3DO Doom wasn't as much slower at the same detail levels as these. And play like this for a better experience (not 5-6fps at worse case but 10-12 and approaching 15-20+ in normal situations). I also added frame limiters to avoid irregular frame rates. And a lot of other gimmicks for fun (Doom on a 3D Cube, distort screen, motion blur,. as I now have the framebuffer back in offscreen texture). Tried to optimize memory a bit (we were hitting some strange cases where Doom would look as it was trying to load/release sprite resources constantly from CD in an endless loop because of low memory) and give options in the starting mod menu, to not load some extra stuff to improve in memory, even reduce max visplanes from default 64 to 32 (Doom doesn't seem on 3DO at least to reach over 32,. most levels are at max 15-23 in few cases) and a check to just stop adding visplanes (and so you get HOMs in the distance if ever) to avoid crashing. I have released this version here http://bugothecat.net/releases/3DO/optidoom/optidoom_main.html As always, folder with few files where you have to provide the commercial 3DO Doom ISO yourself and just run the batch file to create optidoom.iso The 0.3 is postponed for next year (I need time and motivation to figure out the tougher goals which may hopefully give the good speed to original Doom without resolution quality degradation), however it's possible to release sooner a 0.2c before the end of this year to fix some minor issues and new things that might come after more testing.
  9. Laura Beyer's Doom,.. LOL NO :)
  10. Optimus

    Behold: Pregnancy Tester Doom!

    I guess that's how you know when to abort Pain Elemental children =)
  11. I played that yesterday and it was better than I expected. These 90s aesthetics are what made me download it. But the gameplay was good at places. It wasn't a 90s WAD where you get lost and walls are doors and such. It was well done, just keeping those ms paint aesthetics, myhouse.wad, etc. The archville teleports made me play the shopping mall area more strategically. The later level where you run through tight walls, tough, I died a lot, but it's fair enough for it's style of gameplay. The final level with the japanese archways was also cool and fun to play. Definitely will have a look at it again when it's finished.
  12. E1M1, when you go upstairs to get the green armor, there are windows looking on the outside. In fact, some early patch WADs which just altered the original E1M1, always added some secret door/teleport that got you outside to that area and extended that place beyond. No really, the Romero rule shouldn't be that you always must give access to outside areas (some of them might be cosmetic anyway). But that it's cool if you give the access to some of the outside areas and highlight with a special item you can observe from inside. It's obviously not true at various other places through episode 1 (for example, the exit room at E1M2, there are windows looking at some outside area there but obviously you can't reach).
  13. I actually have 8MB on my 386, but good point about smartdrive
  14. I just tried a more heavy vanilla WAD, Suspend in Dusk Sorry for the flickering CRT :P Results: Classic Doom HD: 4.8FPS, LD: 8FPS Fast Doom HD: 5.3FPS, LD:9.6FPS Fast Doom LD with untextured but shaded flats: 10.3FPS Fast Doom Potato, untextured/unshaded flats: 17FPS
  15. I found the review in another greek magazine https://archive.org/details/USER_46/page/n23/mode/2up but not the one I remember (PC Master). I am gonna read it because it's fun! In the editorial of this USER issue, it says "DOOM: The best arcade adventure game of all generations!" LOL At the time, there was a genre called "arcade adventure" but it was for games that were not purely leasure point and click adventure, but needed some tight controls from the player, but mixed this with puzzle solving, e.g. platforms like Jet Set Willy, or some other where you both have to jump over enemies but also carry items with you that you will use, like Dizzy series. The term was more popular in 8bit home computers, which the authors were familiar before. So, I guess Doom was arcade adventure for them, since it has action and needs reflexes, but also sometimes you hunt for the key or press switches like a puzzle or adventure game? Funny..