Join us on Discord!
You can help CodeWalrus stay online by donating here.

Unnamed 3DS homebrew

Started by Hayleia, May 12, 2016, 08:25:32 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Dream of Omnimaga

Wait, I might not get it, but how did you get your texture to look this smooth in the video when in that zip file they're so small and pixelated? I mean, I know on the Nintendo 64 textures are blurred to look smoother, but in your video there's no blur and they look HD and crisp. O.O
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Hayleia

Quote from: DJ Omnimaga on May 20, 2016, 04:04:34 AM
Wait, I might not get it, but how did you get your texture to look this smooth in the video when in that zip file they're so small and pixelated? I mean, I know on the Nintendo 64 textures are blurred to look smoother, but in your video there's no blur and they look HD and crisp. O.O
Ah no, you're right thinking that's not possible :P

I actually have several sets of textures (since they're generated from a script, it doesn't take much more time to just add a resizing pass). The "16x16 ugly ones" that I use for testing since they compile faster, and the "128x128 smooth ones" that I used in the videos and that I'll use in releases (when release time comes).

I guess I zipped the ugly set :P

Dream of Omnimaga

Ah I see. Do you plan to use the lower res textures for stuff drawn in the distance to increase rendering speed like some 3D games do?
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Hayleia

Quote from: DJ Omnimaga on May 21, 2016, 06:42:45 PM
Ah I see. Do you plan to use the lower res textures for stuff drawn in the distance to increase rendering speed like some 3D games do?
I'm not sure it increases rendering speed. From what I learned, it was primarily to reduce ugly artifacts and nonsense patterns that appeared when having a textured object in the distance. Maybe it increases rendering speed as a side effect but I'm not sure about it since it needs more calculations (since now, instead of having one texture and reading from it, you first have to add calculations to decide which texture you're going to read from then do the usual thing... and actually no, you still have more to do since trilinear mipmapping reads from two textures and weighs the two reads from what I recall, so you're doing more twice the amount of work you'd do with one texture only).
In any case, I'll see if I need it when (if ever) the time comes.

Duke "Tape" Eiyeron

Well, it'll decrease performances because more data is pushed to the GPU. Also I don't remember if the gpu does mipmapping from its own.
  • Calculators owned: A lot.

Dream of Omnimaga

Ah ok, I always thought it had something to do with lower end GPU's
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

ben_g

That too. Especially in open-world games, distant objects are loaded with less details and everything has lower resolution textures. The lower detail of distance objects increases rendering performance, and the lower resolution textures take up less memory.

Decreasing the resolution of textures only decreases the memory requirements if no object close to the player needs a higher resolution version of the same texture though, since then you even need to keep 2 instances of the same texture in memory.

Dream of Omnimaga

Thanks for explaining :). That makes more sense now
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Hayleia

No really, I can't get the paint to behave the right way. I can't even get it to behave the way it did in previous screenshots (even though it was already wrong). So maybe people here can help.

Before we start, obviously, you'll need some background.
So, there are two colors. Or more three. "Nothing", "Orange", "Purple".
Each tile has 5 components. Middle, Up, Down, Left, Right.

Obviously, when you shoot a color to a tile, its middle takes the color.
->
But then, when you shoot on two neighbour tiles, it would get ugly if they looked like this
What you want is to change add purple on the right side of the left tile, and add purple on the left side of the right tile :
Same stuff to do on up and down sides obviously.
But then you know, if you shoot orange on the left tile, its middle change but its side have no reason to
This kind of stuff becomes annoying quite quickly.

Ok, so now, the order of textures.
Well first of all, the number of textures -.-
Each size can have 3 values, there are 4 sides, so we already have a 3⁴ here.
Now, the middle can have 3 values... yes, but when it's empty, we know that the whole tile is empty. So we don't multiply 3⁴ but 3 here, but only by 2 (for orange and purple) then we add 1 (for all empty).
This makes a total of 163 textures. Great. Now the order.
Say m is the color (from 0 to 2) of the middle, u is the one for the up side, etc. The texture for the tile is given by
• if empty: 0
• otherwise: (m-1)*3⁴ + u*3³ + d*3² + l*3¹ + r*3⁰ + 1

So now that you know everything, can someone help me write a function? :P
Basically, a tile has attributes which are
• u,d,l,r, pointer to obvious neighbour tiles
• color, which is the texture number, not just the middle color
• an ID, to check if a neighbour is the tile itself (so if it has no neighbour, in other words, and yeah, I could just have used NULL but w/e)
• other things not relevant here
So yeah, the question is, when you shoot on a tile with a color c (0 to 2), what is the new color (0 to 162)?

The function below works if there is only one color in the game:

void setPieceColor(piece* p, uint8_t color, uint8_t setNeighbours)
{
// get the old side colors on the tile (we will replace some of them but others will not change)
uint8_t o = p->color;
uint8_t om=0, ou=0, od=0, ol=0, or=0;
if (o) {
om = (int)((o-1)/pow(3,4))+1;
ou = (int)((o-1)/pow(3,3))%3;
od = (int)((o-1)/pow(3,2))%3;
ol = (int)((o-1)/pow(3,1))%3;
or = (int)((o-1)/pow(3,0))%3;
}

uint8_t u = p->u->color;
uint8_t d = p->d->color;
uint8_t l = p->l->color;
uint8_t r = p->r->color;
uint8_t um = (u-1)/pow(3,4)+1;
uint8_t dm = (d-1)/pow(3,4)+1;
uint8_t lm = (l-1)/pow(3,4)+1;
uint8_t rm = (r-1)/pow(3,4)+1;
if (p->u->id == p->id) u = color; else u = u ? um==color ? color : ou : 0;
if (p->d->id == p->id) d = color; else d = d ? dm==color ? color : od : 0;
if (p->l->id == p->id) l = color; else l = l ? lm==color ? color : ol : 0;
if (p->r->id == p->id) r = color; else r = r ? rm==color ? color : or : 0;
p->color = (color-1)*pow(3,4) + u*pow(3,3) + d*pow(3,2) + l*pow(3,1) + r*pow(3,0) +1;

if (setNeighbours) {
if (um == color) setPieceColor(p->u, um, 0);
if (dm == color) setPieceColor(p->d, dm, 0);
if (lm == color) setPieceColor(p->l, lm, 0);
if (rm == color) setPieceColor(p->r, rm, 0);
}
}

And I have no idea if there is useless stuff in it. I tried so much stuff that I don't remember how it started and why it looks like that now -.-

But now, when using two colors, it doesn't exactly do what I want. See this example where I painted a lot of orange then shot one drop of purple on one tile (you can guess which one).


So, that function is wrong. Any idea of how to fix it ? And any idea why only one side has that little overflow and not the other ones ? I mean, if they all had a problem, I'd just have a problem. But here I have a particular problem and that bothers me even more -.-

(Also @DJ Omnimaga, here is a screenshot with ugly textures :P)

ben_g

Does the 3DS support pixel shaders? If it does, then it's probably easier to create a single texture used to identify in which 'zone' a pixel is (middle, left side, top right corner, ...) and use a set of flags so that the pixel shader can colour each area accordingly. This will take up slightly more rendering time, but it will make it easier to program and free up a lot of (graphics) memory.

Hayleia

#25
Quote from: ben_g on May 29, 2016, 06:38:58 AM
Does the 3DS support pixel shaders? If it does, then it's probably easier to create a single texture used to identify in which 'zone' a pixel is (middle, left side, top right corner, ...) and use a set of flags so that the pixel shader can colour each area accordingly. This will take up slightly more rendering time, but it will make it easier to program and free up a lot of (graphics) memory.
It does but it doesn't answer my question at all. Because even if I used 5 textures (up, right, down, left, middle) and mixed them in the shader only, I'd still have to know which ones I have to mix so the question about the value from 0 to 162 to be computed still applies.

edit Problem fixed. The problem came from another part of the code and this function actually works (at least from what I tested).

Dream of Omnimaga

Glad you got it fixed. I was gonna ask if you had backups of your previous working code in case :P
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Hayleia

Quote from: DJ Omnimaga on May 29, 2016, 07:38:53 PM
Glad you got it fixed. I was gonna ask if you had backups of your previous working code in case :P
Yes but it wouldn't have helped much. I changed the way the program works (no longer uses cubes but can use whatever) so if I used exactly the same function as before, it would have expected cubes and would not even have compiled, and if I used a modified version of it to work with whatever... well that's exactly the function in my previous post :P

Dream of Omnimaga

What I meant is that sometimes, when we code, we do updates that breaks our previously-working code, then no matter how hard we try, we can't seem to fix it back, which sometimes requires restoring a previous backup (and losing progress)
  • Calculators owned: TI-82 Advanced Edition Python TI-84+ TI-84+CSE TI-84+CE TI-84+CEP TI-86 TI-89T cfx-9940GT fx-7400G+ fx 1.0+ fx-9750G+ fx-9860G fx-CG10 HP 49g+ HP 39g+ HP 39gs (bricked) HP 39gII HP Prime G1 HP Prime G2 Sharp EL-9600C
  • Consoles, mobile devices and vintage computers owned: Huawei P30 Lite, Moto G 5G, Nintendo 64 (broken), Playstation, Wii U

Hayleia

Yeah, I got that. But what I basically said is that last time paint was working was before a major rewrite. And it never worked after the rewrite. So I'd restore a backup of a pre-rewrite state to rewrite again and have the same problems actually :P

Powered by EzPortal