You are not logged in.

Read the FAQ and Knowledge Base before posting.
We won't make a 3DS/2DS emulator.



#26 2007-04-15 15:28:27

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

I've finally got it working!
As suspected the issue was a 64bit one!

I simply changed

#define fix2float(v)    (((float)((signed long)(v))) / (float)(1<<12))

To

#define fix2float(v)    (((float)((s32)(v))) / (float)(1<<12))

And it works now. Basically, the problem was that a long is 64bit on amd64 and emt64.
So i can see the alpha problem now :-)

http://organact.mine.nu/dokuwiki/lib/ex … teos01.png

Offline

#27 2007-04-15 17:09:23

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

Look at those lovely blocks!

Come the clean rewrite I will make sure any types are defined sizes (where it matters).

Offline

#28 2007-04-15 17:20:58

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

I forgot to mention, but of course your wave machine works now.

I see that the type problem will also occur elsewhere as it is right now, i'll make a different post about that.

Offline

#29 2007-04-16 20:23:36

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

Part one of the CVS commit is in (not the 3D rendering part).
The GTK build now has optional openGL rendering of the screen. This is only available if the configure script finds the gtkGLext library installed.
There are now some command line arguments to enable this:

./desmume --disable-sound --opengl-2d --soft-convert ~/NintendoHacking/Demos/0034zookeeper.nds

disable-sound disables the sound emulation.
opengl-2d enabled the use of opengl to render the screen.
soft-convert converts the 5_5_5 BGR format to 24bit RGB before creating the texture (faster or slower depending on hardware).
help will display the available options and exit.

The options and the nds file can come in any order.

On my ATI 9200SE card the combination of opengl-2d and soft-convert give slightly better frame rates than the non-openGL method.

P.S. what happened to evilynux's types thread?

Offline

#30 2007-04-16 20:37:17

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

masscat wrote:

P.S. what happened to evilynux's types thread?

I killed it following a discussion with shash.

Offline

#31 2007-04-16 20:42:57

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

masscat wrote:

Part one of the CVS commit is in (not the 3D rendering part).
The GTK build now has optional openGL rendering of the screen. This is only available if the configure script finds the gtkGLext library installed.
[...]
On my ATI 9200SE card the combination of opengl-2d and soft-convert give slightly better frame rates than the non-openGL method.

Great job!
FWIW, on my NVIDIA GeForce4 MX440, soft-convert is about 6fps slower.

Offline

#32 2007-04-17 17:08:15

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

Part two of the commit is in (the 3d emulation).

You can disable the 3D emulation with the --disable-3D option.

Interesting performance issue:
On my nvidia go7600 laptop I get poor performance if 3D emulation and OpenGL screen rendering are both enabled (separately things run fine). It appears to be a problem with the screen render being direct rendering and the off-screen pixmap being indirect rendering (X client or server side). Performance can be much improved by supplying --gdk-gl-force-indirect (a gdkGLext option).
This is not a problem on my ATI 9200SE system.

Offline

#33 2007-04-18 03:35:16

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

3D works great! Thanks!

Just like you, i've a performance hit if i enable opengl-2d. That's unless i use --gdk-gl-force-indirect.

Also, I've commited a small fix in glCoordTex(), missing cast to s16 that shash fixed yesterday.

Note: It seems my Super Mario 64 crashes aren't caused by your version of the 3D code... It seems to be a 64bit env. specific problem again. Segfaulting...

Source and destination overlap in memcpy(0x5A20E0, 0x5A2120, 128)
    at 0x04a22603: memcpy (mc_replace_strmem.c:116)
    by 0x00442415: process_mtx_pop (opengl_collector_3Demu.c:854)
    by 0x00440340: gtk_3D_Flush (opengl_collector_3Demu.c:1182)
    by 0x0042741d: OP_STR_P_IMM_OFF (arm_instructions.c:5093)
    by 0x0041132b: armcpu_exec (armcpu.c:248)
    by 0x0040b029: desmume_cycle (NDSSystem.h:218)
    by 0x0040ec8d: EmuLoop (main.c:1376)
[...]

I do see that there's an overlap as 0x5A20E0+128 = 0x5A2160.

The MatrixCopy function does like this:

memcpy (matrixDST, matrixSRC, sizeof(float)*16);

The function is called with mtxCurrent[] which are 16*float. I don't understand the problem.

Ideas?

Last edited by evilynux (2007-04-18 03:40:30)

Offline

#34 2007-04-18 13:48:56

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

There was a bug in the call list handling which may cause seg faults/strange behaviour. Fix committed to CVS.

The bug was with 3D commands with zero parameters (e.g. END_VTXS) appearing as not the first command in a packed call list command set.

Not sure it would cause your problem though evilynux.

Offline

#35 2007-04-18 15:37:32

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

Yes, thanks masscat, it fixed it!

Edit: I've spoken too quickly, Mario 64 no longer segfaults (altho image looks corrupted), but NFSU2 still does.

Last edited by evilynux (2007-04-18 15:50:02)

Offline

#36 2007-04-19 20:38:33

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

With the latest fix (x should have been z), the situation improved but there are still coordinate errors:
http://organact.mine.nu/dokuwiki/lib/ex … io6402.png

Edit:
I had a quick look at what's going on in Mario64...
It's using unimplemented features (Vertex3_cord_3Dgl_collect) that modifies the texture coordinates...

That may explain the difference between the windows and gtk UIs.
See this post for windows screenshots (thx snkmad):
http://forums.desmume.org/viewtopic.php?id=71

And the link above for the gtk one.

Last edited by evilynux (2007-04-20 03:23:38)

Offline

#37 2007-04-20 12:56:13

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

Support for the XY, XZ and YZ vertex commands has been added (possibly the cause of the seg fault in NFSU2).
The 3D emulation features have been brought up to (or close to) the features of the current CVS Windows 3D emulation.

I am going to stop work on the 3D emulation for a bit as I am going to work on some GDB debugger stub code.

Offline

#38 2007-04-20 13:59:26

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

masscat wrote:

Support for the XY, XZ and YZ vertex commands has been added (possibly the cause of the seg fault in NFSU2).
The 3D emulation features have been brought up to (or close to) the features of the current CVS Windows 3D emulation.

I am going to stop work on the 3D emulation for a bit as I am going to work on some GDB debugger stub code.

There are huge improvements, small regressions and NFSU2 is unchanged.

NFSU2 still segfaults at the same place:
Program received signal SIGSEGV, Segmentation fault.
MatrixCopy (matrixDST=0x5a31a0, matrixSRC=0x5c59556da8642045) at matrix.c:137

Mario64's title screen is worst at some places... That used to be perfect, there's a "blue filter" now:
http://organact.mine.nu/dokuwiki/lib/ex … io6408.png

Mario64 as a whole is much better:
http://organact.mine.nu/dokuwiki/lib/ex … io6403.png
http://organact.mine.nu/dokuwiki/lib/ex … io6404.png

There seem to be a coordinate offset as the caracters seem to be "in the ground", i can see the head if i jump:
http://organact.mine.nu/dokuwiki/lib/ex … io6407.png

As a whole, good job!

Offline

#39 2007-04-20 16:56:08

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

More CVS activity:

Fixed the cause of the seg fault. The number of stored parameters in the call list handler was too small so if used with certain commands it would go blatting over random memory (hence the strange matrix memory copy).

Forgot to implement the multiply by 4x3 and 4x4 matrix functions. Polygons will appear where they weren't before.

The blueness of the Mario64 title screen is how it is supposed to be (if I remember correctly). It is like it is under water. The reason it changed is that I put in the code in to emulate the feature.

Last edited by masscat (2007-04-20 17:24:55)

Offline

#40 2007-04-20 21:03:40

snkmad
Member
Registered: 2007-03-17
Posts: 141
Website

Re: GTK 3D implementation discussion

Yeah the blueish thing is on win port too.
t1754_blueish.JPG


Athlon 64 X2 3800+ / 2Gb DDR2 800Mhz
Geforce 8600GT 256MB / Windows XP PRO SP3
http://desmume.org/compatibility-list/

Offline

#41 2007-04-20 23:17:17

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

snkmad wrote:

Yeah the blueish thing is on win port too.

Oops, my bad.

After testing the latest changes, wow! That's pretty damn close to the windows port.
Thanks a bunch and great job Masscat.!!

Offline

#43 2007-04-21 16:58:33

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

Mario gets a proper face.

The NDS can issue commands to change the ModelView matrix during primitive definitions. OpenGL does not like such things so I have changed to use software vertex transformation (leaving the ModelView matrix as the identity matrix). This adds/corrects some polygons.
I have also enabled alpha blending. This is not all good as I do not fully understand how the NDS orders rendering of transparent polygons so some solid polygons will become hidden. You can disable alpha blending in opengl_collector_3Demu.c by commenting out:

#define ENABLE_ALPHA_BLENDING 1

This is really going to be the last 3D work I do for a bit.

Ben

Note: the changes are in revision 1.9 of opengl_collector_3Demu.c

Last edited by masscat (2007-04-21 17:00:00)

Offline

#44 2007-04-21 17:39:42

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

masscat wrote:

Mario gets a proper face.
[...]
This is really going to be the last 3D work I do for a bit.

It's now nicer than the windows port (in CVS, can't speak for shash's WIP); Incredible work!
Thanks alot Masscat!!

Mario face with correct backgorund and working alpha:
http://organact.mine.nu/dokuwiki/lib/ex … io6414.png

Offline

#45 2007-04-21 21:23:05

shash
Administrator
Registered: 2007-03-17
Posts: 897

Re: GTK 3D implementation discussion

Wow, that looks nice. Could you be a bit more concise how did you do the polygon reordering? Because that's how it's supported, isn't it? Because my plug-in already supports changing modelview on primitives submission, so some type of quad strip reording must be there, no? I'll check the code when I've some free time smile In my current WIP, only the face is wrong, the alpha is exactly as in that shot.

EDIT: Forget that, I just realized, that the problem in my current implementation is that if the change of the modelview is done not on a single primitive completion, but in the middle, you "lose" that primitive. The already done stuff works correctly for the next primitive in the same batch, but it's wrong for the "current" one. For example, in my implementation, if a batch of 10 triangles are sent on the same GL_TRIANGLES, it works correctly if the modelview is changed between one or more of those ones, but not if done in the middle of a single triangle creation. I'll add this to my core in a few, as it's fairly easy to do smile Thanks for the idea, as it helped me realize why my implementation was wrong for certain cases.

Offline

#46 2007-04-21 21:44:54

snkmad
Member
Registered: 2007-03-17
Posts: 141
Website

Re: GTK 3D implementation discussion

I tried compiling Gtk Glade under under windows here using dev-cpp. After adding gdk_3Demu.c gdk_3Demu.h and opengl_collector_3Demu.c opengl_collector_3Demu.h i still got 20 errors:
obj/main.o(.text+0x9ce):main.c: undefined reference to `init_opengl_gdk_3Demu'
obj/main.o(.text+0x9e2):main.c: undefined reference to `NDS_3D_SetDriver'
obj/main.o(.text+0x9e7):main.c: undefined reference to `gpu3D'
obj/main.o(.data+0x0):main.c: undefined reference to `gpu3DNull'
obj/main.o(.data+0x4):main.c: undefined reference to `gpu3D_opengl_collector'
obj/GPU.o(.text+0x6c66):GPU.c: undefined reference to `gpu3D'
obj/MMU.o(.text+0x71a):MMU.c: undefined reference to `gpu3D'
obj/MMU.o(.text+0x778):MMU.c: undefined reference to `gpu3D'
obj/MMU.o(.text+0x92e):MMU.c: undefined reference to `gpu3D'
obj/MMU.o(.text+0x971):MMU.c: undefined reference to `gpu3D'
obj/MMU.o(.text+0xa22):MMU.c: more undefined references to `gpu3D' follow
obj/gdk_gl.o(.text+0xfe5):gdk_gl.c: undefined reference to `gluErrorString'
obj/gdk_gl.o(.text+0x10c5):gdk_gl.c: undefined reference to `gluErrorString'
obj/gdk_gl.o(.text+0x12db):gdk_gl.c: undefined reference to `gluErrorString'
obj/gdk_gl.o(.text+0x1304):gdk_gl.c: undefined reference to `gluErrorString'
obj/gdk_gl.o(.text+0x1490):gdk_gl.c: undefined reference to `gluErrorString'
obj/gdk_gl.o(.text+0x15f0):gdk_gl.c: undefined reference to `gluOrtho2D'
obj/gdk_gl.o(.text+0x165e):gdk_gl.c: undefined reference to `gluErrorString'

What am i missing?
Also what the -rdynamic option do? I always get on windows: gcc.exe: unrecognized option `-rdynamic'

Last edited by snkmad (2007-04-21 21:52:14)


Athlon 64 X2 3800+ / 2Gb DDR2 800Mhz
Geforce 8600GT 256MB / Windows XP PRO SP3
http://desmume.org/compatibility-list/

Offline

#47 2007-04-21 22:44:24

masscat
Member
From: UK
Registered: 2007-03-17
Posts: 73
Website

Re: GTK 3D implementation discussion

shash:
There are a couple of problems with the replaying of the previous vertices.

1. You have to replay any per vertex commands that went along with them (colour, normal or similar).

2. You have to transform the replay vertices from their own ModelView spaces into the new one. This would involve applying the origin matrix and the inverse of the new matrix before sending it off to OpenGL set to the new ModelView matrix.

Since, for a quad strip replay, you could have to replay up to three previous vertices and the ModelView matrix can be changed per vertex (I think) this could all get a bit messy (and time consuming).
So I went for the easy option of doing all vertex ModelView transforms in software and sending them to OpenGL set with a ModelView matrix of the identity matrix.


snkmad:
Cannot help with Windows specifically but:
init_opengl_gdk_3Demu is in gdk_3Demu.c. The gpu3D stuff is in render3D.c and render3D.h. The glu stuff should be in a system library similar to the opengl stuff.

Offline

#48 2007-04-21 23:36:22

snkmad
Member
Registered: 2007-03-17
Posts: 141
Website

Re: GTK 3D implementation discussion

Hum i also added render3D.c render3D.h, now the gpu3D errors are gone.
My guess is i need to add even more files to project.
Ill take a look on the linux makefile, maybe it help.
Maybe i just need a list of what files should go into the project...

Last edited by snkmad (2007-04-22 00:03:11)


Athlon 64 X2 3800+ / 2Gb DDR2 800Mhz
Geforce 8600GT 256MB / Windows XP PRO SP3
http://desmume.org/compatibility-list/

Offline

#49 2007-04-22 02:21:19

shash
Administrator
Registered: 2007-03-17
Posts: 897

Re: GTK 3D implementation discussion

masscat: I just fixed it in my current WIP, as it was rather easy to fix. In a few days I'll profile and only transform when needed, to get as much speed as possible. In fact, the matrix class has a matrix*vector function, so I just used it when setting up vertices, et voila, perfecta mario! I guess I'm just too used to PC graphic cards, so I just thought that the matrix change would work on anything lower than primitive level, so thanks to make me realize that on the DS, per vertex matrices aren't rare tongue

t1758_SuperMario64.png

Sorry, I know this is a bit offtopic, but couldn't resist. I'll commit it when I optimize it a bit.

evilynux wrote:

It's now nicer than the windows port (...)

Not anymore XD

Offline

#50 2007-04-22 02:38:30

evilynux
Member
From: Montréal
Registered: 2007-03-17
Posts: 118
Website

Re: GTK 3D implementation discussion

shash wrote:
evilynux wrote:

It's now nicer than the windows port (...)

Not anymore XD

Glad to hear that ;-)
I mean, there's a good momentum. The ports are healty.

snkmad
Did you work this out?

Btw, "-rdynamic" is required (at least on GNU/Linux) for callbacks to work.
Basically, if it's not there, there won't be any events binded to the user interface.

Do you have GLU installed?

Offline

Board footer

Powered by FluxBB