to mupen makers

[non4lf3]

dear mupen staff i have this minor glitch with puyo puyo 4 puyo puyo party its splitting everything (exept the puyos) are split and skeleton-T is minorly glitched when you play against every character i suppose you should fix it (Recommended):mupen64:



Your
mupens biggest fan
non4life

 

[nmn]

First _WOW_. Thought i was the only one who tried.

Second, I noticed this bug, have yet to report it (cuz i forgot, my bad). I myself have not found the issue but its probably not an obvious one. The sprites seem to be split at every few pixels vertically.

 

[non4lf3]

i will show you if i have time wait i think i know the solution were running the wrong format of mupen64 ::akuma:

 

[nmn]

Sorry I worded that badly, I noticed the problem but i was talking about finding what the source was. Its obviously a huge issue - Barely effects the playability but still annoying nonetheless.

I can't help with this issue right now. I've checked on the code before, but right now I'm in Windows (A modified version of XP) to do various tasks (Trust me, i don't like it... I miss having multiple desktops really badly.)

 

[smcd]

but right now I'm in Windows (A modified version of XP) to do various tasks (Trust me, i don't like it... I miss having multiple desktops really badly.)

Thread offtopic, but http://virtuawin.sourceforge.net/ is handy for "when you have to be on Windows"

 

[Richard42]

I may have found the source of this problem. I made a change today which greatly helps this issue. You can still see tiny lines between the textures but not huge gaps anymore. I just hope it doesn't cause problems for other games.

 

[nmn]

This was a particular annoying bug, what did you do to cause an improvement?

(And virtuawin is decent but ReactOS explorer implements it better so i'll just use it when i want multidesktops)

 

[Richard42]

This was a particular annoying bug, what did you do to cause an improvement?

You should have seen the email notification when I made the commit the other night. These objects were being drawn in a different function than most others (DrawSprite) and the coordinate calculation code was throwing this -1 offset into the x1,y1 coordinates before they get scaled to the final screen coords. It was causing a gap of 2 pixels between textures which are supposed to be adjacent. It's still not perfect, and I believe that there needs to be some kind of offset in either the texture u,v coords or the screen coords, but the old code was clearly wrong. At any rate it looks a lot better now even though it's still not really exact.

 

[nmn]

I need to get Linux booting again I'd like to try to finish this one off.

 

[Richard42]

I ran another experiment tonight to check on the values of the texture wrapping parameter in this function (DrawSprite) that has the problems. It turns out that sometimes it had invalid values for the wrapping parameter at that point in the code (maybe it never gets properly set beforehand; I didn't really scour the code to figure out how it's supposed to work). I added some code to force it to GL_CLAMP_TO_EDGE and it looks almost perfect now.

 

[nmn]

Thats cool, now i want to play >_> damn GRUB

 

[Richard42]

I need to get Linux booting again I'd like to try to finish this one off.

Sorry nmn, I would have left it for you if I'd have known that you were going to look at it. Good luck getting your distro up and running again. I did an update on my gentoo box for the first time in about 2.5 months on Sunday and it took just over a day to get it all updated and put back together - 330 new packages. GNOME 2.20, new kernel, firefox/thunderbird, all the rest. This is what I love about open source.

 

[nmn]

Actually, I just wanted to finish it off because that one sounded bad. I didn't know you were going to look into it, so i wanted to. Its definitally always a good thing to fix a bug.

Oh, and yeah, I need to get Gentoo up... That would be a good setup.

 

[Richard42]

Actually, I just wanted to finish it off because that one sounded bad. I didn't know you were going to look into it, so i wanted to. Its definitally always a good thing to fix a bug.

Oh, and yeah, I need to get Gentoo up... That would be a good setup.

Now I'm trying to track down the rect texture problems on my MiniPC system with the Intel 965 chipset. I ran an experiment this morning and found that OpenGL is throwing a bunch of GL_INVALID_VALUE errors somewhere; this may be related to the texture problem. I'll track it down and fix it tonight and see if that helps.

I think for a software developer who is comfortable with unix administration, Gentoo is by far the best distro to use. My primary desktop PC has been running 64-bit gentoo for over 2 years and it's the most stable OS I've ever used. I think I had to unintentionally reboot maybe twice in that time. It does take more time and effort to manage, but for me it's worth it. I have not reinstalled the OS in 2 years but I'm running the most up-to-date packages. At one point I upgraded from GCC from 3.x to 4.x - that's just not possible with other distributions. The ABI changed, and Portage had to rebuild every single library and binary from source.

The only caveat is that things do break from time to time when upgrading, and you need to have a pretty good knowledge of the whole system in order to fix it properly.

 

[nmn]

Well, The array of problems with texturing have existed for a while, its definitally good to see the progress that was made already. I'm glad to see how fast bugs are being fixed too.

Anyways, I'll be trying to install gentoo likely as a primary OS. I do know how to solve almost any break issues (with some exceptions) but i never really expeirenced one in the years i've used Gentoo. (Except for one where i accidentally destroyed /usr - can you believe i got lucky enough to fix that without rebooting?)

 

[Richard42]

Well, The array of problems with texturing have existed for a while, its definitally good to see the progress that was made already. I'm glad to see how fast bugs are being fixed too.

Yeah I fixed the opengl error last night but it didn't help my texture issues. I did find a new lead on that during my tests though. I discovered that it's using multitexturing for the problematic rectangles, so I bet that the problem is in the multitexture or combiner setup. I haven't dug into that corner of the code yet so this should be interesting.

Good luck w/ the Gentoo setup. Step up to the plate with a stage 1 install.

 

[nmn]

Well, I have to admit to having problems like this when programming tile based games in OpenGL. It was a very long time ago and i forgot the way i used to fix it. But hey, ricevideo does work alot better on the game with these fixes in. I'm gonna go get the trunk now and read through a bit of code.

 

[Richard42]

Well, I have to admit to having problems like this when programming tile based games in OpenGL. It was a very long time ago and i forgot the way i used to fix it. But hey, ricevideo does work alot better on the game with these fixes in. I'm gonna go get the trunk now and read through a bit of code.

I think the Puyo Puyo 4 issues are mostly solved - it looks pretty good now. There are similar issues in other games, though -- I saw some misaligned textures in S.F. Rush. I thought it may have been caused by my changes so I locally reverted that change and tested it, but the problem remained, so the problem is in a different area. These kinds of things should be relatively easy to find and fix. The texture problem that I had on my MiniPC was a bear to find. In the end I believe it is a driver bug -- when I simplified the fragment program code in a certain way, the problem went away. I filed a bug on freedesktop.org yesterday.

 

[nmn]

The issues are mostly solved for sure. It looks like subpixel values may be having a problem, or as you said, it could be related to multitexturing. Otherwise alot of the graphics are now fine. The game runs alot nicer now. Though i can't wrap my head around why this game runs so slow on effects even with dynamic recompiler on (in 32 bit builds of course). I doubt its slowing down because of graphics, but i could be wrong.

 

[Richard42]

The issues are mostly solved for sure. It looks like subpixel values may be having a problem, or as you said, it could be related to multitexturing. Otherwise alot of the graphics are now fine. The game runs alot nicer now. Though i can't wrap my head around why this game runs so slow on effects even with dynamic recompiler on (in 32 bit builds of course). I doubt its slowing down because of graphics, but i could be wrong.

I noticed something while I was testing with this game (Puyo Puyo 4). It creates a whole lot of textures when all the colored stars are flying around at the start of a game, and it pushes the memory usage up by several hundred MB. It ran okay on my 2GB gentoo box but caused disk swapping on my 1GB MiniPC. I bought 2GB of ram for the MiniPC because of this.