Jump to content

KulorXL

Members
  • Posts

    101
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

KulorXL's Achievements

Chopper Commander

Chopper Commander (4/9)

188

Reputation

  1. That was 100% the problem. I followed the instructions on this video: Located this bodge wire on the back of my board... Snipped it off, and soldered on this different bodge wire... ...and now it works perfectly! So if anyone's trying to get an HxC working on an Amiga 1200, and it just doesn't want to actually load anything, this is worth looking into.
  2. Update, I discovered my Amiga is apparently an Escom revision, which are notorious for having issues with these things. Going to attempt a bodge fix, and will document the results here.
  3. To clarify, the full output of the display alternates between: T:002/080 S:0 T:003/080 S:0 So that part does remain at 0. The handful of images I've tried all behave the exact same way. I am in the US, and actually I just remembered I might have a single real floppy game sitting around that I can try, but if I can't dig that up, I will definitely take you up on that offer, much appreciated!
  4. I'm having an issue with mine and I'm wondering if anyone else with this setup can show me how they're supposed to behave when working properly. I bought this preconfigured USB HxC, with a preconfigured thumb drive, but it doesn't seem to want to actually load anything. I'm replacing the internal floppy drive. The screen turns on and lets me select a disc image, and when I get to the purple "insert a floppy" screen, the piezo buzzer clicks, and the HxC seems to indicate that it's trying to read different tracks, but the Amiga never actually detects that there's a disc. The screen on the HxC continually alternates between T:002/080 and T:003/080, with a piezo click every time it switches. The S:0 never changes. What are these supposed to say when it's working properly? Anyone have any ideas for what the issue might be? Allegedly the Amiga worked perfectly with the original drive, but I have no floppies with which to verify that.
  5. This one is awesome but you have to be pretty familiar with the original, it's basically the four movements rearranged in the style of the reverse order (I.E. movement 4 in movement 1's style, movement 3 in movement 2's style etc.): This one's by the same guy, please stick this one out for the ending, it's definitely worth it (can you spot all the references?):
  6. Looks like sprite line limits being exceeded. Basically, the SNES (and Genesis and PCE etc.) are like the NES, in that they can have a ton of sprites on-screen, but only so many on the same line at a time, and if you go above that limit, any extras just won't render on those lines. NES games often had flicker systems as part of their sprite drawing routines because going over the very sparse limit on the NES was extremely common, but on 16-bit systems, the limit is much more generous: you have just enough sprites to cover the entire screen horizontally on the Genesis, PCE, and SNES. Nobody really bothered coding sprite flicker on these systems because of this (yes you had to code the sprites to flicker on the NES), so when the sprite line limit is exceeded, parts tend to just disappear instead.
  7. Awesome game! Something I always gotta mention because I don't think most people are aware, but for some reason, they gave you control over the brightness in the menu. This brightness setting controls an SNES register called INIDISP, which is usually set to 15 by default, and decremented down to 0 to fade the screen to black for easy screen transitions. But the default brightness setting in Axelay is 11 for some reason...which means the screen is constantly partially faded to black the whole time unless you set the brightness up to max. It's a very strange design choice, I can't think of any other game that did that, and I think most people are playing this game with needlessly muted colors as a result. Here's the default brightness setting: ...and here's what it looks like at full brightness: So definitely crank the brightness in the menu for the best possible colors.
  8. AFAIK nothing is known about how that port works yet, aside from "it's using a chip for something", but I suspect the audio playback won't be streamed to the SPC. The SNES provides pins for the cartridge to feed in expansion sound directly, no streaming needed; this was how the Super Gameboy and Satellaview did their audio stuff.
  9. Fucking finally. Never post my shit or talk about my game again.
  10. It only works on 8bpp modes, which are modes 3, 4, and 7. It also only works on the 8bpp layer in those modes. Did you give up on it then? You never even tried to show us what it can do.
  11. Guess I gotta do it my damn self, alright... Here's Kirk's sky BG using 8 palettes: Here, I've crunched it down to using only 4 palettes instead of 8: I don't have the original asset, so I'm basically taking Kirk's 8 palette one and crunching it down even further, which means the dithering is double-stacked; it'd look better if I had converted from the original truecolor source. Still, you could have an artist touch it up and it would look pretty much the same quality as the 8 palette version, and especially if you cut out the sky gradient in the BG and just did that with HDMA instead -- a lot of color entries are wasted trying to dither the gradient, which isn't a great use of them. Here's the sky island, crunched down to a direct color palette: This one actually doesn't convert too terribly, and you get a nice color count of 169. Nice! Still though, the shaded parts in particular don't look great, because there's not a lot of subtle hues to go in there when you're working with the direct color palette. Here's what it looks like with 75 colors in indexed 8bpp: The rest looks pretty much the same, but the shaded parts fare a whole lot better. And here's a 4bpp layer using 4 palettes: The shaded parts look worse than 8bpp, but better than direct color still, and nothing else is appreciably worse. Here's Kirk's 8 palette 4bpp BG with the direct color island superimposed: Here's my 4 palette 4bpp BG with the 75 color 8bpp indexed island superimposed: And, the real kicker, here's my 4 palette 4bpp BG with the 4 palette 4bpp island superimposed: ...and that one uses *half* the VRAM for the island portion. So this basically lines up with what I observed when I was playing with direct color mode some number of years ago: it doesn't really win against the other options you have. Doing the same graphics in 4bpp halves the VRAM usage and often looks at least as good, if not outright better; doing the same graphics in 8bpp indexed also looks at least as good, while opening the door to do cool color cycling tricks as well (which are not possible in direct color mode). So once again, I don't think you've made a compelling case for using direct color here, you're gonna have to come up with something better if you want to convince me.
  12. Sounds like you're pretty convinced this is a good use case for direct color mode. Let's see it, then. What does that island look like when converted to direct color specs? Also, did you really need 8 palettes for that sky? What does the scene look like if the sky used only 4 palettes, and the island used either 64+8+3 indexed colors in 8bpp, or just the 4 other palettes on a 4bpp layer instead? Direct color has to look noticeably better than either of those options, which shouldn't be a problem, right?
  13. Yeah, I mean if the chips themselves are dying, there's not a whole lot else you can do...and the SNES was a pretty bomb console, so a lot of people put a ton of hours on theirs, which means you're likely to run into failing chips 30+ years on, so drop-in replacement chips are inevitably gonna be needed at some point. Sure it wouldn't be 100% the exact same (unless someone like decapped a PPU and rebuilt it from that I guess?) but we gotta make concessions somewhere when we're essentially playing on antiques.
×
×
  • Create New...