Previous Page | Next Page
- by dj4uk6cjm at 12:37 PM EDT on June 6, 2017
- I've begun re-playing the Streets of Rage Remake game for PC again recently and still find it highly enjoyable, I wish they would bring back their original website but I'm having fun trying out the mods from their forum. If anyone is into old beat-em-up games definitely check it out!
I'm also catching up on my favorite tv shows on the CW over the summer, mostly The Flash, The 100, Supernatural and The Originals (only 3 episodes left of this season!) and finishing up some miniscule video game remixes in Mixcraft 8, has anyone used it yet as well? It just released earlier this year and I love it! Especially now since Celemony Melodyne comes pre-installed with it. :)
- by AnonRunzes at 11:36 AM EDT on June 7, 2017
- I wonder what $v#, $t# and $a# actually stand for in MIPS programming...
- by hcs at 11:40 AM EDT on June 7, 2017
- (Return) Value, Temporary, Argument. And s is Saved.
See this PDF which spells out the conventions.
edited 11:42 AM EDT June 7, 2017
- by AnonRunzes at 1:06 PM EDT on June 7, 2017
- @hcs - Thanks for that doc, I`ll remember that one.
- by SmartOne at 12:20 AM EDT on June 9, 2017
- I attended the premiere of this in 2006: https://en.wikipedia.org/wiki/Play!_A_Video_Game_Symphony
No money to buy the awesome program (there was a full page of Squall Leonhart's scarred face over his gunblade! Lost forever!). The venue was awesome. The sound quality was great. I heard Koji Kondo perform the New Super Mario Bros. theme on piano before the game was released. Was his performance a world premiere? Yasonori Mitsuda was there. Nobuo Uematsu was there. And Silent Hill guitar guy. And others.
I attended Distant Worlds a few years later. Arnie Roth (has he played a video game in his life?) was more confident this time. The amplification at the venue was absolutely awful. Clipped to hell. When the audience was prompted, I yelled to indicate my preference for arranging "Battle on the Big Bridge" next. The populace yelled for "Jenova" louder... Or was it "Dancing Mad?" Don't remember.
The real reason I decided to get up and post today:
Rogue Galaxy
Dragon Quest VIII: Journey of the Cursed King
Both games developed by Level 5. Level 5 did great work developing screen-tearing-free Dark Cloud 2. Even previously quality-minded Square Enix produced Dragon Quest VIII.
Rogue Galaxy has screen tearing in the battle system. Otherwise pretty game.
Dragon Quest VIII has screen tearing... the whole damn time? At least while walking around the first town.
Now the Internet knows. Points for me. This report is based on playing the games on the PS2 from an internal IDE hard drive using Open PS2 Loader. I don't think the faster-than-DVD-drive loading is causing the screen tearing. I do think the faster loading is exposing duration-locked streaming music code, because entering and exiting the menus in both games makes the music hiccup. When faster hardware causes bugs, that's absolutely attributed to poorly written software. Faster than minimum hardware should only make software run even better.
Summary of huge bugs in aforementioned, lauded games:
1. Rogue Galaxy: Battle system screen tearing
2. Dragon Quest VIII: Whole-damn-time screen tearing
3. Both games: Faster storage medium causes streaming music skips during menu transitions
By the way, yes, screen tearing is absolutely a bug (it's objectively bad). Developers have two (funny how that number pops up so often in logic) choices:
1. Optimize your renderer to eliminate screen tearing
2. Render less to eliminate screen tearing
Option #3: Screen tearing, is invalid. Stop choosing it when you write code. K?
edited 12:27 AM EDT June 9, 2017
- by hcs at 10:30 AM EDT on June 9, 2017
- I agree about tearing, always sucks.
As for relying on timing, I don't know... With streamed audio on consoles things tend to be tightly tuned because the platform is standard, there's little reason to test what will happen with super fast seeking if there's no expectation it could ever happen. I expect even the dev units duplicate this timing even though it works off a hard drive, so that bugs don't only appear on retail hardware.
That said, Level 5 did do their own audio system for those games, so it likely didn't get as much care put into it as the SDK streaming system, which I suppose is more robust with this kind of thing if you're only noticing it in these two games.
Anywho not trying to argue too much, just wanted to bring up a little context.
It's funny how there's kind of the opposite problem with most USF rips (or so I am told): because PJ64 completes a lot of DMAs instantly, the tracer strips out the code that handles waiting for the DMA, so when it is run with real delays it crashes from that code being missing. Oops.
---
Play sounds like an awesome experience! I missed the first Video Games Live show at the Hollywood Bowl by a day when I was out there visiting, and even went there for a different concert! Still regret that to this day, even though I've seen VGL shows 3 times since and am kind of tired of it now. Speaking of obnoxious MCs...
edited 10:35 AM EDT June 9, 2017
- by SmartOne at 3:10 AM EDT on June 10, 2017
- Haha, oh Arnie.
Yeah, emulators and tight timing. But, like you said, that's the opposite problem. Emulators need to emulate the "minimum requirements" (AKA the hardware). I don't see how faster hardware would make correct software break, unless busy waiting/sleeping is inefficient?... Sounds like a software problem.
- by kode54 at 10:37 PM EDT on June 11, 2017
- In this case, it was incorrect emulation being used as a base mark to trim "unused" code and data from the ROM sets before shipping them as USF sets. I checked the original player code, lots of interrupts fire instantly instead of simulating delays.
LazyUSF2, based on Mupen64Plus, has to disable lots of these timing delays in playback because of rips that will go haywire if timing is realistic.
I don't blame the rippers, either, since they used the tools available to perform the trimming. I sort of blame the trimming software, which is why I wrote my own coverage routines based on the Mupen64Plus emulator core in my library. When using coverage mode, it will enable all delayed timing as closely as the emulator core supports. It also forces full low level RSP emulation, even if that is still designed to execute and return instantly. Maybe that can be improved upon in a future version, if upstream hasn't already dealt with it?
- by hcs at 11:17 AM EDT on June 12, 2017
- I wonder if there's a place for a tag that indicates "use real DMA timing", like _enableFIFOfull (which attempts to do the right thing with audio DMA timing, Excitebike wouldn't work without it once the other threads were killed). That way an accurate player can support new, accurate sets without having to throw out all the broken, but still listenable, sets.
(Or a new format made with hindsight that just runs a ROM...)
Sorry about the tracer/stripper/sparse tool. Even between the modded PJ64 used for ripping and 64th Note there are significant differences​. I should have known I had more work to do when I had to add a setting to include code within N bytes of any accessed word.
---
While I've got some edit time left, I've made myself a monument to stupidity over the last two days. I bought The Little Prover some months back, yesterday I got it into my head to really dig into it. So I spent about a day putting together an interpreter for the subset of Scheme the book uses, in JavaScript. Then I spent way too much time today manually typing in the proof assistant from the back of the book, when I knew the files were available online.
Fortunately when I was done and things didn't work I came slightly closer to sensibility, I grabbed the files directly, and things were still broken. I cross-checked with MIT Scheme and the code seemed to work OK there, so there was something I was missing.
That something turns out to be that quoted stuff is actually stored as (quote x), so (eq? 'quote (car ''x)) is true. This is similar to how all lists have 'nil hidden at the end, but I had known about that one already.
In any case I went back and checked the stuff I had manually keyed it, it was broken anyway so it's a good thing I didn't waste any more time on it. I'm glad my interpreter works (at least for the very few things I tested it on), but it's pretty slow. It's triggered by the 'change' event rather than 'input' since it was too slow to update on every keystroke, 'change' tends not to fire until the textarea loses focus.
edited 3:02 AM EDT June 13, 2017
Over the last week I also polished off an old pixel editor and worked on a triangle/quadrilateral sketch simplifier/recognizer for mouse/touch.
edited 3:06 AM EDT June 13, 2017
edited 3:08 AM EDT June 13, 2017
- by hcs at 3:43 PM EDT on June 14, 2017
- New version of the J-Bob interpreter is 10x faster. Still inscrutable. Took down the old one, added more code so it's still running in about 1 second on most of my devices.
The key was that a profiler (always a good idea to use!) indicated most of the time was spent in name lookup. There are a lot of shortcuts we can take because of how simple the language is: no nested functions, functions aren't used first class, no redefinition, the only variables are arguments. So now most lookups are done ahead of time and I save an index to use when running.
What I'm down to now is most likely more closely related to the overall architecture, lots of recursion and most JavaScript engines still don't do tail call optimization.
[edit]
Actually, the performance may not be my fault after all. MIT/GNU Scheme runs it in about the same time (slightly slower) on my desktop: 734ms, vs 648ms for Firefox 54.
Of course that doesn't count the whole page load time which I didn't measure and which probably makes it a somewhat unfair comparison. But being within an order of magnitude of the official implementation in a real Scheme system is gratifying.
edited 4:18 PM EDT June 14, 2017
Previous Page | Next Page
Go to Page 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202
Search this thread
Show all threads
Reply to this thread:
HCS Forum Index
Halley's Comet Software
forum source