- Status
- Joined
- Dec 5, 2009
- Messages
- 839
- Trophies
- 1
- Age
- 30
- Location
- center of the Sun
- Website
- kuribo64.net
- XP
- 2,498
- Country
It's planned.
Also, fucking shit. Something the hardware renderer made evident is that there are games that modify the palette mid-frame. A particularly mean trick.
Cool Spot does that with the colors used by its HUD, for whatever reason. DKC also does it to do the sky color gradient (why it's done that way escapes me, it could just change the subscreen backdrop color).
That shit is going to be a bit tricky to emulate.
Quick tests reveal that while it's okay to emulate it for Cool Spot, DKC does it on many scanlines (nearly half the screen), which makes things slow as shit.
A smarter mechanism could help in such cases, by for example detecting which layers are affected by the palette changes and splitting only those layers. But even then, that shit is still a pain to emulate in the hardware renderer.
Also, fucking shit. Something the hardware renderer made evident is that there are games that modify the palette mid-frame. A particularly mean trick.
Cool Spot does that with the colors used by its HUD, for whatever reason. DKC also does it to do the sky color gradient (why it's done that way escapes me, it could just change the subscreen backdrop color).
That shit is going to be a bit tricky to emulate.
Quick tests reveal that while it's okay to emulate it for Cool Spot, DKC does it on many scanlines (nearly half the screen), which makes things slow as shit.
A smarter mechanism could help in such cases, by for example detecting which layers are affected by the palette changes and splitting only those layers. But even then, that shit is still a pain to emulate in the hardware renderer.
- Joined
- Feb 10, 2009
- Messages
- 5,484
- Trophies
- 2
- Location
- Sacramento, California
- Website
- lazerlight.x10.mx
- XP
- 5,499
- Country
Finally got CN in the mail, and the first thing I did after installing the ninjhax was try this emu. It works rather well, especially the hardware-accelerated version (even if it is unofficial).
I'm just going to throw out this idea, but first, how fast can the system render polygons, and how many do you think it can do in a frame's worth of time? Can it do multi-texturing on a single polygon? The problem with dealing with graphic rendering of the SNES is that graphics (excluding those designed for Mode-7) are organized in bit-plane form. StapleButter has done a great job with the tile-cache method to generate tiles of the appropriate 16-bit format usable by the hardware, but this recent development of palettes changing on the H-Blank would mess with this approach. Now, onto some things regarding my idea (that I'll get to afterwards).
From what I understand, you are able to set a polygon's color (in a similar fashion that glColor does in OpenGL), in that if it is set to full white, a non-textured polygon will also be white and a textured one will have the texture act like no color alterations were made. When set to 50% for each color component, the non-textured will be grey and the textured one will be dimmed by 50%. And black, well, both will be black. Now, imagine a 2-bit paletted-texture applied to a polygon (with color 0 being transparent). On the texture, there are only 3 colors. Imagine that you separated those colors and placed them on individual textures. Now, set all those "filled" pixels to complete white. Now, take 3 quad polygons, assign one of these unique textures to each, and overlap them in the same spot. A white silhouette of the original texture. Now, for each polygon, assign the color (like with glColor) to what the textures originally were colored with. What you have now is, with the use of multiple textures and polygons, a representation of a 2-bit paletted texture without actually having paletted-texture support. If a color of the original palette changes, you just change the color to the corresponding polygon, and voila. If you need a visual representation of what I'm talking about, here's a shoddy example that I made when thinking of porting my Megaman 2 PTC project to the 3DS SmileBasic (which does not have paletted support)
So, here's my question. Does the 3DS GPU have enough polygonal power to do something like this for background layers and sprites? I'm just thinking of 15 textures that are of the size of the SNES VRAM (in 16-bit form) that contains all white but various pixels are set as 0 (for the alpha) to represent the 2/4-bit graphics (8-bit would require 127 of these textures, and I think that's too much, both in 3DS VRAM usage and polygons to render per tile). When the emulator writes to the SNES VRAM sections, the emulator would also set the pixels for the various textures to be either on or off (if the area being written is related to graphic cels). Then, during the actual render phase, polygons are rendered using these textures and having them set with the glColor equivalent to match the color palette row (3 polygons for 2-bit and 15 polygons for 4-bit, no need to render one for color 0). If multi-texturing is supported, it could reduce the number of polygons that would need to be rendered.
....does this make any sense, and if it does, is it even a plausible idea?
I'm just going to throw out this idea, but first, how fast can the system render polygons, and how many do you think it can do in a frame's worth of time? Can it do multi-texturing on a single polygon? The problem with dealing with graphic rendering of the SNES is that graphics (excluding those designed for Mode-7) are organized in bit-plane form. StapleButter has done a great job with the tile-cache method to generate tiles of the appropriate 16-bit format usable by the hardware, but this recent development of palettes changing on the H-Blank would mess with this approach. Now, onto some things regarding my idea (that I'll get to afterwards).
From what I understand, you are able to set a polygon's color (in a similar fashion that glColor does in OpenGL), in that if it is set to full white, a non-textured polygon will also be white and a textured one will have the texture act like no color alterations were made. When set to 50% for each color component, the non-textured will be grey and the textured one will be dimmed by 50%. And black, well, both will be black. Now, imagine a 2-bit paletted-texture applied to a polygon (with color 0 being transparent). On the texture, there are only 3 colors. Imagine that you separated those colors and placed them on individual textures. Now, set all those "filled" pixels to complete white. Now, take 3 quad polygons, assign one of these unique textures to each, and overlap them in the same spot. A white silhouette of the original texture. Now, for each polygon, assign the color (like with glColor) to what the textures originally were colored with. What you have now is, with the use of multiple textures and polygons, a representation of a 2-bit paletted texture without actually having paletted-texture support. If a color of the original palette changes, you just change the color to the corresponding polygon, and voila. If you need a visual representation of what I'm talking about, here's a shoddy example that I made when thinking of porting my Megaman 2 PTC project to the 3DS SmileBasic (which does not have paletted support)
So, here's my question. Does the 3DS GPU have enough polygonal power to do something like this for background layers and sprites? I'm just thinking of 15 textures that are of the size of the SNES VRAM (in 16-bit form) that contains all white but various pixels are set as 0 (for the alpha) to represent the 2/4-bit graphics (8-bit would require 127 of these textures, and I think that's too much, both in 3DS VRAM usage and polygons to render per tile). When the emulator writes to the SNES VRAM sections, the emulator would also set the pixels for the various textures to be either on or off (if the area being written is related to graphic cels). Then, during the actual render phase, polygons are rendered using these textures and having them set with the glColor equivalent to match the color palette row (3 polygons for 2-bit and 15 polygons for 4-bit, no need to render one for color 0). If multi-texturing is supported, it could reduce the number of polygons that would need to be rendered.
....does this make any sense, and if it does, is it even a plausible idea?
I'm using the .3dsx so hopefully I can get some support with this minor issue. Whenever I try to play EarthBound it works fine but the amount of experience needed to level up to 2 is asinine. 245734, in other words the amount that is normally needed to reach level 34.
Play the same rom through a computer emulator or Android emulator and it's the normal amount needed. 4.
Any ideas?
Play the same rom through a computer emulator or Android emulator and it's the normal amount needed. 4.
Any ideas?
- Joined
- Dec 5, 2009
- Messages
- 839
- Trophies
- 1
- Age
- 30
- Location
- center of the Sun
- Website
- kuribo64.net
- XP
- 2,498
- Country
DiscostewSM I don't quite get what you mean, that's some complex shit you've got there. But if I get it right, it'd only work for 2bpp tiles, because the 3DS can only apply 3 textures to the same polygon. Unless you use multiple polygons, but then the more you use polygons and the more it defeats the purpose of the hardware renderer-- transferring less data per frame).
As for the polygon limits of the PICA200, you can check Wikipedia for the theoretical limits at some given frequencies, and extrapolate for 268 MHz which is what the 3DS GPU is said to be running at. According to my calculations there's more than enough to render big heavy frames.
rayword45 That's a quite interesting issue. Looks like some bad CPU bug. Probably the same reason why the layer in the intro scrolls too fast and goes out of range. Do you have a save that would let me quickly reproduce that issue? I really want to debug that shit.
Unrelatedly, I have mode 7 working in the hardware renderer. Except it's a software fallback for now. It seems to take some frameskip when in use, too.
I'll think about a hardware mode for later, for use when the mode7 coordinates aren't too small. The coords can be as small as 1/256, which means that there would be 32 tiles in one single pixel; the amount of geometry it would take to render that assuming the coords are changed every scanline would be insane, even if optimizing out overlapping tiles.
Edit- what the hell, will you stop glitching and eating what I type, Firefox? How about you work more on being less of a piece of shit and less on trying to be a Chrome clone?
As for the polygon limits of the PICA200, you can check Wikipedia for the theoretical limits at some given frequencies, and extrapolate for 268 MHz which is what the 3DS GPU is said to be running at. According to my calculations there's more than enough to render big heavy frames.
rayword45 That's a quite interesting issue. Looks like some bad CPU bug. Probably the same reason why the layer in the intro scrolls too fast and goes out of range. Do you have a save that would let me quickly reproduce that issue? I really want to debug that shit.
Unrelatedly, I have mode 7 working in the hardware renderer. Except it's a software fallback for now. It seems to take some frameskip when in use, too.
I'll think about a hardware mode for later, for use when the mode7 coordinates aren't too small. The coords can be as small as 1/256, which means that there would be 32 tiles in one single pixel; the amount of geometry it would take to render that assuming the coords are changed every scanline would be insane, even if optimizing out overlapping tiles.
Edit- what the hell, will you stop glitching and eating what I type, Firefox? How about you work more on being less of a piece of shit and less on trying to be a Chrome clone?
hi staplebutter have a question for you why in this video(2:46) he uses the blargsnes and have sound?
p.s.:sorry for my english
p.s.:sorry for my english
Woah I saw this vid and never even thought about that. You're an observant one you are.
Oh for the love of Batman. https://mega.co.nz/#!LJpC0ASK!Jke6Snsfs2sOkQyxfFUC1alGvH6zt9b6tjwdxVKwmm8
How do most emulators do it?
Or do they just do it in software since it's only going to slow down significantly on less powerful devices?
got this same exact bug so I started playing another game lol
edit
also returning to the blargsnes menu and starting a different game will freeze my 3ds up
- Joined
- Apr 29, 2011
- Messages
- 31,284
- Trophies
- 2
- Age
- 38
- Location
- Dr. Wahwee's castle
- XP
- 18,969
- Country
Me thinks you guys are using that version which link was shared not to long ago, yes? If so, well, best of luck.
naw I'm using the build thats supported by this thread, not the hardware accelerated sound build (although I did try that one out last night)
- Joined
- Apr 29, 2011
- Messages
- 31,284
- Trophies
- 2
- Age
- 38
- Location
- Dr. Wahwee's castle
- XP
- 18,969
- Country
Ah, my mistake, wasn't sure just wanted to double check
no big deal
I just started a new game in openemu and moved the sav over to my sd card and my game freezes at the load save menu at the beginning.
here's the srm that glitches exp made in blarg (glitches in the menu on snes9x)
https://www.dropbox.com/s/dx3ockjlrj3soxl/Earthbound (U)q.srm?dl=0
here's the one I made with openemu snes9x (doesnt work in blarg)
https://www.dropbox.com/s/q4wgah20wlls8op/Earthbound (U).srm?dl=0
essentially neither of them are playable
playing evo search for eden perfectly ( getting owned by sharks though )
so kudos the devs your work is highly appreciated
- Joined
- Dec 5, 2009
- Messages
- 839
- Trophies
- 1
- Age
- 30
- Location
- center of the Sun
- Website
- kuribo64.net
- XP
- 2,498
- Country
PC emulators do it in software, like everything else.
As far as Snes9xTYL goes, I haven't looked closely. It seems it does it in software but is able to hardware-accelerate simple cases.
lolSNES and SNemulDS map the mode7 layer to one of the DS layers in rotoscale mode. DS rotoscale works the same was as SNES mode7.
rayword45 thanks for the save, but I realized a bit too late I didn't need it, just have to press a couple buttons to bring the stats panel
Anyway, uh...
Was indeed a CPU bug. Instructions TXA and TYA when A is 8-bit but X/Y are 16-bit. I'll have to remember this because lolSNES has the same bug.
Oh and it also fixes the insanely fast scrolling in the intro, unsurprisingly. Well, the game has a 32-bit multiply routine, and the bug broke it, so anything that used it would get wrong results
- Status
Similar threads
-
Sicklyboy
-
K3Nv2
-
Xdqwerty
what are you looking at? -
HiradeGirl
-
-
-
-
-
-
-
@
Sicklyboy:
@Xdqwerty, wire is definitely more practical IMO. Hell these days you can charge a laptop over USB, can't charge a laptop wirelessly though. Wireless chargers, even "fast" ones, are only good for slowly charging devices, plus they generate a good amount of heat too+1
-
@
Sicklyboy:
Can plug my phone in and charge from 0 to 50% in like 20-30 minutes, Would take an hour+ on wireless charging
-
-
-
-
-
-
-
-
-
-
-
-
@
Sicklyboy:
Power banks can be incredible depending on your needs. 1) I have a 100w capable one that can charge my laptop. 2) Same one can also power my soldering iron (though is overkill for it) 3) a BIG power bank I have with an AC outlet on it can power my desktop weed vape during a power outage
-
@Sicklyboy I have this: https://www.amazon.com/gp/product/B0BJQ7F16T/ref=ox_sc_saved_title_8?smid=AKXVBT49GGF3B&psc=1
It works great. But no AC outlet. -
@
Xdqwerty:
@HiradeGirl, I finally did talk to my brother (although only about my pills and anxiety)
-
-
-
