|
Post by supper on Dec 18, 2021 14:01:49 GMT
Well, I was on the fence about this one when I posted the Yuna 1 translation a few months back, but in the end I came around. So for better or for worse, here's Galaxy Fraulein Yuna 2 in English! Download it here: stargood.org/trans/yuna2.phpYouTube video of the opening: www.youtube.com/watch?v=-T7S_P1MNbY (I didn't bother recording gameplay because if this doesn't interest you, the actual game sure won't) Yuna 2 is pretty much exactly what you'd imagine the sequel to the first game to be: the same basic ideas, but more. Well, not so much "more" in terms of the writing (it's actually a good bit shorter than the first game), but the audiovisuals and general presentation are far more refined and focused -- it's pretty obvious they were going all-in on the idea of making a game that was as anime-like as possible. Basically, don't expect much real gameplay, but there's a fun little plot to be had if you're into this kind of thing. In technical terms, this was easier than Yuna 1 in some ways and more difficult in others, but it probably ended up being about the same overall. As always, the subtitles were the hardest part, but since I was able to reuse the core logic from the subtitling system I made for the first game, it wasn't too bad. I had to pull some interesting tricks to deal with the more complex scenes in this game, though -- for instance, to make it possible to work in subtitles around the raster-based sprite cropping, the translation runs a "minimization" algorithm to prevent game sprites from being drawn outside the cropped area as much as possible. Things got a little dicey sometimes, but it works! This time, I did the hacking and main translation, Mafoo343 translated the manual and provided tons of help with pretty much everything else, TheMajinZenki checked the script to try to keep me out of trouble, and cccmar and Xanathis tested the game. Thanks to everyone for contributing! It's not a game for everyone, but I hope a couple of you out there will enjoy this one.
|
|
|
Post by dshadoff on Dec 18, 2021 15:03:50 GMT
Awesome work again, Supper !! I can't wait to play this.
Watching the introduction on Youtube, you've done an outstanding job again in terms of quality and technical excellence !
|
|
4lorn
Deep Blooper
Posts: 27
|
Post by 4lorn on Dec 18, 2021 15:57:59 GMT
Excellent work, supper - and everyone else involved, too
|
|
|
Post by spenoza on Dec 19, 2021 2:43:47 GMT
Holy balls! Fan-dang-tactic work on that into! Also, great work from Hudson in that intro!
|
|
|
Post by turboxray on Dec 19, 2021 6:21:55 GMT
supper - at the second rcr, sprites and bg are both disabled, forcibly blanking the remainder of the screen. mednafen does not like having the lower bound of the crop set higher than 0xF2. this will result in the lower-bound crop triggering after the vsync handler, which ends up disable bg for the entire screen. this appears to just be an emulation bug, though. using a lower value like 0xF0 instead will fix it regardless.
Can you expand on this a little further? Update: Nevermind I see it. I'll add it to the test list for my up coming break.
|
|
|
Post by supper on Dec 19, 2021 8:00:28 GMT
supper - at the second rcr, sprites and bg are both disabled, forcibly blanking the remainder of the screen. mednafen does not like having the lower bound of the crop set higher than 0xF2. this will result in the lower-bound crop triggering after the vsync handler, which ends up disable bg for the entire screen. this appears to just be an emulation bug, though. using a lower value like 0xF0 instead will fix it regardless.
Can you expand on this a little further? Update: Nevermind I see it. I'll add it to the test list for my up coming break. Here, it might help to show the relevant code from the original game. Here's the disassembly for the RCR interrupt handler used during cutscenes: ; standard rcr interrupt vector
; check if "wavy line" effect on? 004245 AD 0C 28 lda $280C 004248 D0 67 bne [$42B1] ; if not, do standard crop effect ; check parity flag: ; zero = starting crop ; nonzero = ending crop 00424A AD 0B 28 lda $280B 00424D D0 37 bne [$4286] ; if at start of crop area 00424F EE 0B 28 inc $280B ; enable sprites 004252 03 05 st0 #$05 004254 A5 F3 lda $00F3 004256 09 40 ora #$40 004258 8D 02 00 sta $0002 ; set bg x 00425B 03 07 st0 #$07 00425D A5 0E lda $000E 00425F 8D 02 00 sta $0002 004262 A5 0F lda $000F 004264 8D 03 00 sta $0003 ; set bg y 004267 03 08 st0 #$08 004269 AD 0D 28 lda $280D 00426C 3A dec 00426D 18 clc 00426E 65 0C adc $000C 004270 8D 02 00 sta $0002 004273 A5 0D lda $000D 004275 69 00 adc #$00 004277 29 01 and #$01 004279 8D 03 00 sta $0003 ; set next interrupt line to end of crop area ; ($280E) 00427C 03 06 st0 #$06 00427E AD 0E 28 lda $280E 004281 85 14 sta $0014 004283 4C 99 42 jmp $4299 ; else if at end of crop area ; reset parity flag 004286 9C 0B 28 stz $280B ; disable background + sprites 004289 03 05 st0 #$05 00428B A5 F3 lda $00F3 00428D 29 3F and #$3F 00428F 8D 02 00 sta $0002 ; == possible entry point == ; (used during initialization) ; set next rcr interrupt line to start of crop area ; ($280D) 004292 03 06 st0 #$06 004294 AD 0D 28 lda $280D 004297 85 14 sta $0014 ; == possible entry point == 004299 64 15 stz $0015 00429B A5 14 lda $0014 00429D 18 clc 00429E 69 3F adc #$3F 0042A0 85 14 sta $0014 0042A2 90 02 bcc [$42A6] 0042A4 E6 15 inc $0015 0042A6 A5 14 lda $0014 0042A8 8D 02 00 sta $0002 0042AB A5 15 lda $0015 0042AD 8D 03 00 sta $0003 0042B0 60 rts ; else ...(wavy line effect code)... $280D is the on-screen scanline number of the upper bound of the crop, and $280E is the scanline of the lower bound. In the code at the end of the "at start of crop area" branch, the game converts the raw lower-bound value at $280E to an RCR value by adding 0x3F (instead of 0x40, to allow a scanline of time for the handler to run), and places the result in RCR. The problem occurs when $280E is set to high values that result in an "offscreen" line being targeted. As noted, the game sometimes sets $280E to 0xFF when it wants there to be no lower bound on the crop. This results in RCR being set to (0xFF + 0x3F) = 0x13E, which corresponds to the "254th" line of the display. Mednafen apparently doesn't handle this case correctly; IIRC what happens is that the VSync handler runs, resetting the control register from $20F5 (to sprites off/BG on), but then the lower-bound RCR interrupt fires before the next frame starts to get drawn, forcibly setting BG to off for the frame. I think the upper-bound crop RCR must be failing to go off, too, as one of the scenes in question uses sprites and those don't show up either. Sorry, it's been a while since I actually tested this and I don't remember all the details... I'm not well versed enough in this aspect of the hardware to know exactly what the correct behavior is here -- naively, it looks to me like the raster interrupt for the lower bound shouldn't be triggering at all in this situation, because if it happens at any point after the VSync interrupt and before the next frame actually starts getting drawn, the background will definitely get blanked out, even if the upper-bound RCR goes off correctly. Maybe someone else has a better idea what's going on here.
|
|
|
Post by turboxray on Dec 19, 2021 18:49:48 GMT
The RCR will fire for any scanline, active, vblank, etc (I've used it to drive 15khz audio demos). It doesn't matter if the display is on or off. If BG is set to 'off, and SPR is set to 'off' when the CR register is fetched by the VDC, then the start of the next frame is in 'Burst Mode', which means the frame is disabled (no BG or sprite fetching - you can't re-enable it until the next frame) and all cpu access slots are available for the entire frame. Since the RCR is firing after vblank, it's changing CR back to BG/SPR -> off. The bug in mednafen appears to be that it's latching CR state at a later time than the real system. I guess this was never an issue because no game does what Yuna 2 was doing haha. I wonder if MisTer has this behavior implemented correctly. But I'll run some tests. I suspect the latch happens pretty close to vblank firing (maybe at the start of the next scanline, since it's an 'inactive' line in the view of the VDC).
|
|
|
Post by elmer on Dec 19, 2021 20:26:14 GMT
I wonder if MisTer has this behavior implemented correctly. But I'll run some tests. I suspect the latch happens pretty close to vblank firing (maybe at the start of the next scanline, since it's an 'inactive' line in the view of the VDC). It'll be interesting to know for sure when you test it, it's a pretty-critical part of the VDC's behavior! If the latching happens pretty-close to vblank, that might help to explain why the System Card's IRQ1 handler processes the vblank *before* the hsync (RCR) interrupt. <EDIT> It is going to be critical to know whether the VDC's VRAM-to-SATB or VRAM-to-VRAM DMA operations affect when the CR is locked, since those operations will stall the CPU if it is trying to write to VRAM ... and IIRC, wouldn't that apply to both ST2 and TIA instructions???
|
|
|
Post by dshadoff on Dec 19, 2021 21:38:23 GMT
I just played the intro of the untranslated game on Mednafen and MiSTer - MiSTer isn't missing anything, but large parts were showing black screen on Mednafen.
I also heard a separate report about "a flashing line", but no details about where it happens, what hardware it was played on, or whether it was also on the original untranslated game... so I can't investigate anything about it.
|
|
nicole
Gun-headed
Posts: 50
Fave PCE Shooter: Magical Chase
Fave PCE Platformer: Legendary Axe II
Fave PCE RPG: Ys III
|
Post by nicole on Dec 29, 2021 20:09:39 GMT
Did a playthrough of this on my SuperGrafx on Twitch and I didn't run into any issues there at least. Great work to the team, it's really impressive!
|
|
roflmao
Punkic Cyborg
Ha! Face-to-foot style. How do you like it?
Posts: 214
|
Post by roflmao on Dec 30, 2021 6:22:13 GMT
Did a playthrough of this on my SuperGrafx on Twitch and I didn't run into any issues there at least. Great work to the team, it's really impressive! Wow Supper! Thanks so much! This is great! What's your Twitch account, nicole? That sounds like a fun watch. I recently finished the first one, and it was excellent!
|
|
|
Post by SignOfZeta on Jan 3, 2022 4:12:47 GMT
Dang. I never thought either game would ever be translated and now both of them are…and not following multiple announcements and multiple delays…it’s just…done. Great job!
It’s been a looong time since I played these games. I got the second one from Die Hard and the first I got as a reprint (HuVIDEO ver) around the same time, from TZD. I do remember the shine on Yuna 2 to be pretty lux but also it’s even less of a game than the original. Whereas Yuna 1 at least gave the illusion of choice Yuna 2 is almost totally linear and doesn’t even pretend to be anything else. It was new stuff at the time though and I still love Mika Akitaka so I’ve always been a fan.
|
|