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

lunaark

Members
  • Content count

    84
  • Joined

  • Last visited

3 Followers

About lunaark

  • Rank
    Registered just to bump a seven year old thread

Recent Profile Visitors

428 profile views
  1. lunaark

    Doom SNES Hacking Guide/Documentation

    I might've fucked something up in the patches, it doesn't seem to be running like my first test, because I redid everything. Will revisit tommorrow.
  2. lunaark

    Doom SNES Hacking Guide/Documentation

    Alright, here are the patches for each region. These are patches specifically to be used for overclocking, running them without any is gonna be unpleasant to say the least. However, if you wanna see how the game ran on Randy's hacked up Star Fox cartridge, running this without any overclocks should be accurate, except for any differences in the release build. This patch disables IRQ and sets the clock register to 10.7mHz, which has been shown to drastically improve overclock potential, especially on real hardware. Refer to above post for more information. Anyways, here you go. Doom SNES Overclock Patches.zip EDIT: To clarify, you should patch with Lunar IPS, or any other IPS patcher (I made it with Lunar IPS, so no guarantees it will work with another patcher). This isn't a ROM, it simply patches your existing ROM. I wouldn't recommend patching your main ROM, make a separate copy to patch.
  3. lunaark

    Doom SNES Hacking Guide/Documentation

    You know how Randy was talking about all the improvements you could make to the engine, given Super FX overclocking, especially in emulators? Well, I just wrote a patch to get the game to overclock much better than before. I got the game running at 85.6mhz with a patch I wrote (in an emulator of course) It was actually quite a simple patch. I saw a video of star fox running at 60mhz on real hardware, even though the limit was thought to be much lower, at like 30 or 40mhz. Well, it turns out that the Super FX has quite a few hardware flags, and setting them correctly can result in a more stable experience when overclocking. Essentially, setting the CLSR register's clock bit to 0, and setting IRQ to 0x80, which is No IRQ/Standard Timings, you can get much better results out of your overclocks. The person who did the Star Fox overclocks seemed to test Doom a little, and they said they got it running better. Apparently, the GSU on the Doom cart sucks and when they swapped it for one. But CLSR set to 0 sets the game to 10.7mHz, which is the same abyssmal performance Randy talked about on his hacked up Star Fox cartridge used for development. However, for some reason, setting the Super FX to this lower frequency allows it to achieve much higher overclocks, and the IRQ removal fixes many glitches and crashes, for reasons I do not know. Removing IRQ does adversely affect the game, notably pausing takes longer and there seems to be very small stutters occasionally, but overall my experience has been great. Setting the clocks lower may help. The game doesn't run maybe as good as an equivalent overclock with the default IRQ and CLSR, but it can definitely push higher, but further testing will be needed. However, this should all work, and greatly benefit both emulators, and people who wish to solder on a new EEPROM to an old Super FX cart, or even overclock a GSU compatible flashcart (if that's even possible) The game appears to run much more consistently and stable compared to typical overclocks, things like weapon sway and movement also seem to more closely mirror the original in terms of pace, etc. This could really open the door for much greater things with the source code release. Also, according to the person who developed this method originally, it does run much better on consoles than emulators. If you ever saw the video of Star Fox running at 57mhz, this is exactly the same person. My patch is currently only for the NA ROM, once I do all the ROMs I'll release the patches as IPS for everyone to go wild and test and whatnot. I'm fuckin pumped.
  4. lunaark

    Doom SNES Hacking Guide/Documentation

    I've done a little digging and I think I'm starting to understand why the source code release is taking so long. Basically, Acclaim owned the rights to the Reality engine, Acclaim went bust, and when their properties were put up for auction, a bunch of companies took their slice of the pie. To paraphrase wikipedia, Yeah... so it's a matter of hunting down who the rights went to, negotiating with them to get the rights back, which could involve alot of money and/or compromises, especially given Randy is trying to release the game under the GPL, and these companies might not be willing to budge so easily. Fuck. I have high hopes for Randy to get the rights back etc, but I don't really think Randy owns the engine as much as people would like to believe. No fuckin clue.
  5. lunaark

    Doom SNES Hacking Guide/Documentation

    Fair point.
  6. lunaark

    Doom SNES Hacking Guide/Documentation

    It's a little tricky still, he's going for the GPLv3 license, for the entire engine and game data. The data itself is the hard part, as ZeniMax are quite trigger happy with lawsuits, especially compared to the old id.
  7. lunaark

    Doom SNES Hacking Guide/Documentation

    Another big revelation, I was fucking around with a memory editor, and I seem to have set off a debug/error handling thing. I have my debugger to break on BRK opcodes in the hopes of finding developer breakpoints, which would imply debug shit. Anyways, this means there's debug shit in the ROM, and I can only imagine the juicy shit you'll see in the source code. I'd imagine shit like a wireframe renderer, coordinate display, fps counter, so much good shit that will help understand the engine. Shit like that would also be great for speedrunners too, to help getting more precision while practicing. I'm fuckin pumped. This source code release will not disappoint, regardless of what can be done in terms of performance optimizations. This is fucking awesome.
  8. lunaark

    Doom SNES Hacking Guide/Documentation

    Ouuuuch. Who would the copyright have gone to?
  9. lunaark

    Doom SNES Hacking Guide/Documentation

    Also, this doesn't mean much, sorry. CacoTube simply still has Randy added, and just forwarded my question. However, Randy did mention that it is coming soon enough.
  10. lunaark

    Doom SNES Hacking Guide/Documentation

    Randy has responded, and here's what he has to say. Although maybe not anything definitive, this is still a good pointer and confirms my hypotheses. Given his wording and the explanation of the rendering engine, it seems the game has really robust optimizations, and it seems that while further optimization in terms of code is possible, it may not net the major gains I was hoping for. Given that the game runs at an average of 9.5 MIPS, it takes 950,000 cycles to draw one frame on average, which is quite large but seems it could be improved, I feel maybe a 10% performance increase at most, which is like, 1 more fps. However, one thing that is extremely possible is getting more consistent framerates and responsiveness. Time will tell, but I'm not too hopeful for any major leaps in performance. Again, the game can still be greatly improved with hindsight, optimizations, general tweaks, and community feedback.
  11. lunaark

    Doom SNES Hacking Guide/Documentation

    Alright, I forwarded a question to Randy through CacodemonTube, and I'm really excited. It was a long question, so it's gonna take him a while to answer. Anyways, he said that the game does in fact have a proper BSP implementation, but it is implied that there is a bunch of trickery going on. I asked about potential optimizations, how the renderer works, pathfinding, etc. To consolidate the information I already have, I do believe that further optimization *is* possible through large community efforts, but the game appears to use the Super FX insanely well, using many optimizations and cache etc. The game manages to push around 7-12 MIPS, and 21 is the theoretical limit of the GSU-2. However, I do believe that more is to be done, especially considering the very small amount of RAM left over, only like 16 bytes. Machine code can get decently big over a long period of time, and quite often longer code that is more efficient is better than smaller code that is less efficient. Also, I do believe there is quite a significant chunk of space to reclaim. As far as I can tell, more or less all of the relevant PC data is in the ROM, and quite a bit is uncompressed as far as I can tell. I believe all sprites are in the game, all textures (excluding flats), all sounds, etc. I will post an update when Randy finds the time to type out his response.
  12. lunaark

    Doom SNES Hacking Guide/Documentation

    Using a noclip cheat, messing with the NODES data, and comparing it to the PC version etc, as well as information from CacodemonTube, I think I can confirm that the SNES port has a proper BSP implementation, and factoring in information from Randy himself I really don't think there's much to optimize. I'm kind of baffled that the game is truly done this well, especially given the lack of information around the Doom engine, BSP rendering, etc.
  13. lunaark

    Doom SNES Hacking Guide/Documentation

    to test my theory, im gonna make a level with a shitload of sectors, but with very few columns, so basically a really subdivided room.
  14. lunaark

    Doom SNES Hacking Guide/Documentation

    very good points, but let me break down my reasoning. to make this simple on myself, im gonna simplify this a little bit. i'm gonna draw how i believe the bsp system works. assuming you are standing in the sector highlighted yellow, the sectors highlighted in red are what you're gonna see. now, we know that textures in snes doom are around 64x64, and when rendered as double width, have an effective resolution of about 32x64. let's assume all columns are rendered 16 pixels tall. e1m1 has 486 linedefs, and around 66% of them are drawn. let's assume a very conservative estimate of 128 units wide per linedef, which is the width of a door, but with 64 actual columns per wall, as the game renders double width. (486*0.66)*64=20,528 columns drawn, and with 16 pixels tall that is about 324,448 pixels drawn, and given randy's pixel renderer pushes 1 pixel per cycle, you're looking at 324,448 cycles to just draw the frame. this sounds like alot, and it probably is, but keep in mind that the screen resolution is 108x144, which is 15,552 pixels directly on screen, so given the massive excess of geometry being rendered vs what is visible, i feel this number is plausible, despite my admittedly shoddy methodology. alright, so we know that 324,448 cycles are taken just to draw the game per frame, how much is that actually for the super fx? well, it runs at 21.447mhz, so let's convert that to hz, and we get 21,447,000 cycles. yikes. so, we know the game runs about 10 fps average, so that 324,448 cycles per frame comes out to 3,244,480 cycles per second used to draw the game, which means ~15.1% of the super fx is dedicated to just drawing the screen alone, however, the actual number of pixels drawn could vary wildly, from a hundred thousand to over double my initial statement, especially on larger levels, which could mean up to 30% of the super fx is used just *drawing* the screen, leaving you with around 70% to actually run the game. then when you factor in the omission of blockmap and reject to speed up line of sight and collision calculations, which both involve heavy trigonometry, math, and BSP fuckery, the weird ass cylindrical collision, demon AI, and literally an entire game, it adds up quite quickly. given the simplicity of the approach i presume randy to have used for bsp, i feel it's relatively inconsequential on performance. please take this all with a fat ass grain of salt, but this is my reasoning.
  15. lunaark

    Doom SNES Hacking Guide/Documentation

    that's really strange, i really can't wait to see this source code. i heard the game uses cylindrical collision (??) but im not too sure about that, i have no clue why they would use such a method, but that would explain the lag, as it's harder to calculate collisions with cylinders, especially mutliple cylinders and overlapping cylinders, than coordinates on a box.
×