You are not logged in.

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



#1 2007-04-07 01:32:55

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

GTK 3D implementation discussion

As mentioned on the mailing list and in the "Using openGL to draw to screen (not doing 3D)" thread, there are some difficulties getting the 3D emulation working under gtk (specifically the gtk-glade port but since openGL is likely to be used for screen rendering in the future (see earlier linked thread) it will apply to the gtk port).

My initial feeling is the problems occurs because GTK is threaded and there are openGL calls happening within the emulation core (3D implementation) and the GTK signal processing thread (screen rendering). This requires careful protection and openGL context switching to allow correct rendering.

To kick off some discussion I have put together a method of do 3D within the GTK signal processor and only do openGL calls within the signal processing function (allowing easy openGL context switching). It renders to screen, implements very little 3D functionality and is only implemented in the plain GTK port but does demonstrate 3D rendering. It renders my wave machine for example.

http://masscat.afraid.org/ninds/tars/test_3d.tar.bz2

Overview:
The commands sent to the NDS geometry unit are stored until the buffers are swapped. At this point a signal is issued to the openGL rendering area. The signal processor then goes through the stored commands performing the openGL calls.

EDIT: forgot to mention, the tarball is for files in the src/gtk/ directory.

EDIT2: through my misunderstanding GTK - the emulation (and therefore the 3D rendering) runs as the idle event of the event processor so there is not a problem of different threads. The 3D render function could be called directly from the flush function.

Last edited by masscat (2007-04-08 10:05:46)

Offline

#2 2007-04-08 14:22:06

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

Re: GTK 3D implementation discussion

I'm unable to get it to build... i must be missing something...?
Please modify the Makefile.am, provide more details on the modifs or provide a full tarball.

Offline

#3 2007-04-08 15:33:08

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

Re: GTK 3D implementation discussion

evilynux:
I have directly changed the Makefile to for incuding/linking to gtkGLext for the gtk build (I do not know how to configure the autotools to do this). You will need gtkGLext installed on your computer. If you run any of the autotools you will have to edit the gtk Makefile again.

The change to the Makefile is:

change:

desmume_LDADD = ../libdesmume.a $(SDL_LIBS) $(GTK_LIBS)
desmume_CFLAGS = $(SDL_CFLAGS) $(GTK_CFLAGS)

to

desmume_LDADD = ../libdesmume.a $(SDL_LIBS) $(GTK_LIBS) $(GDKGLEXT_LIBS)
desmume_CFLAGS = $(SDL_CFLAGS) $(GTK_CFLAGS) $(GDKGLEXT_CFLAGS)

Here is an updated version which using openGL to do 3D (off screen) and the screen render, added some features from the Windows build too (texture mapping):

test2_3d.tar.bz2

Offline

#4 2007-04-08 22:12:53

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

Re: GTK 3D implementation discussion

Hmm... I had compile errors, had to add "../matrix.c" to the sources.
That said, your wave machine doesn't seem to work for me even tho i've tried to follow the hints.

Bottom screen remains pink..:
http://organact.mine.nu/dokuwiki/lib/ex … aves01.png

Edit: Oh, the rendering is being done off screen so it's normal i don't see a thing!?

Last edited by evilynux (2007-04-08 23:00:22)

Offline

#5 2007-04-09 00:07:25

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

Re: GTK 3D implementation discussion

Here is the meteos demo running (the blocks are rendered using 3D, it shows the combined 2D and 3D and texture mapping from the test2 tarball):

meteos2.jpg

and my wave machine:

wave.jpg

The wave machine showing just a pink screen is not good. What are you running on?

In the first tarball the 3D rendering is done to an on-screen (i.e. visible) gtk drawing area (256x192) placed below the main screen. This extends the window by one third. The 2D rendering continues happily as normal.

In the second tarball (the screenshot version) the 3D rendering is done to an off screen gdk pixmap and then merged with the 2D image through shash's 3D interface. The combined NDS image is then drawn to screen using a textured quad (similarly to the gtkGLext enabled gtk-glade port). If you are only getting a pink lower screen in the wave machine then it is likely that the 3D rendering to the pixmap is not working. Is there any debug output from GTK/GDK (any output that does not start with "GTK 3D render") suggesting that some initialisation is failing? I have run the code on an ATI 9200SE card (from where the screenshots were taken) and a Nvidia 7600go. Both display a combined 2D and 3D image.

On the nvidia I appear to lose the alpha channel for the 3D render so transparent objects block the 2D display behind them so there is some more work required on the pixmap use.

EDIT: Just a note: there is lots of work required on lots of things (not just the pixmap use) and much tidying up of the source. This is still very much an experiment to see if using openGL for 3D rendering and screen drawing can be made to work. So any feed back is useful.

Last edited by masscat (2007-04-09 00:27:54)

Offline

#6 2007-04-09 21:47:40

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

Re: GTK 3D implementation discussion

masscat wrote:

The wave machine showing just a pink screen is not good. What are you running on?

Ultra modern nVidia GeForce4 MX440 ;-)
With the 9xxx series driver (i.e. i even have GL_EXT_texture_from_pixmap).

masscat wrote:

If you are only getting a pink lower screen in the wave machine then it is likely that the 3D rendering to the pixmap is not working. Is there any debug output from GTK/GDK (any output that does not start with "GTK 3D render") suggesting that some initialisation is failing?

Not at all!
e.g. Both your wave machine and Meteos show "Doing GL init" (if i ignore all GTK 3D Render statements).

Beyond the fact that i get "GTK 3D render error:Unhandled" statements, the blocks aren't visible at all in Meteos.

Edit: An extract from the logs shows that there's something going on even tho i don't see a thing: http://organact.mine.nu/dokuwiki/lib/ex … meteos.log

How can I be helpful?

Last edited by evilynux (2007-04-10 04:51:50)

Offline

#7 2007-04-10 09:16:17

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

Re: GTK 3D implementation discussion

evilynux:
The log is just showing the NDS geometry commands being processed by the 3D emulation code. The lines like "GTK 3D render error:Unhandled 34" are just features of the NDS that are not being emulated yet.
I was hoping to see some errors from the GDK, GTK or gtkGLext libraries showing what feature is not correctly configured or failing to be set up. The fact that you get the 2D output shows that your system is doing some openGL successfully so I think the problem must lie in the off-screen rendering which may not be supported on your hardware or I have not set up gtkGLext correctly to use it.

I do not know what extension or openGL feature gtkGLext uses for off-screen rendering. Anybody know this or another portable method for setting up off-screen rendering?
Here are the extensions supported by my ATI card:

OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 9200SE DDR Generic
OpenGL version string: 1.3.1060 (X4.3.0-8.24.8)
OpenGL extensions:
    GL_ARB_multitexture, GL_EXT_texture_env_add, GL_EXT_compiled_vertex_array,
    GL_S3_s3tc, GL_ARB_occlusion_query, GL_ARB_point_parameters,
    GL_ARB_texture_border_clamp, GL_ARB_texture_compression,
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar,
    GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat,
    GL_ARB_transpose_matrix, GL_ARB_vertex_blend, GL_ARB_vertex_buffer_object,
    GL_ARB_vertex_program, GL_ARB_window_pos, GL_ATI_element_array,
    GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_ATI_map_object_buffer,
    GL_ATI_texture_env_combine3, GL_ATI_texture_mirror_once,
    GL_ATI_vertex_array_object, GL_ATI_vertex_attrib_array_object,
    GL_ATI_vertex_streams, GL_ATIX_texture_env_combine3,
    GL_ATIX_texture_env_route, GL_ATIX_vertex_shader_output_point_size,
    GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate,
    GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_clip_volume_hint,
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_multi_draw_arrays,
    GL_EXT_packed_pixels, GL_EXT_point_parameters, GL_EXT_rescale_normal,
    GL_EXT_secondary_color, GL_EXT_separate_specular_color,
    GL_EXT_stencil_wrap, GL_EXT_texgen_reflection, GL_EXT_texture3D,
    GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map,
    GL_EXT_texture_edge_clamp, GL_EXT_texture_env_combine,
    GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
    GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp,
    GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_vertex_array,
    GL_EXT_vertex_shader, GL_HP_occlusion_test, GL_NV_blend_square,
    GL_NV_occlusion_query, GL_NV_texgen_reflection, GL_SGI_color_matrix,
    GL_SGIS_generate_mipmap, GL_SGIS_texture_border_clamp,
    GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays
glx server vendor string: SGI
glx server version string: 1.2
glx server extensions:
    GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating,
    GLX_EXT_import_context, GLX_OML_swap_method, GLX_SGI_make_current_read,
    GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier,
    GLX_SGIX_fbconfig
glx client version: 1.3
glx client extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_ATI_pixel_format_float,
    GLX_ATI_render_texture
glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
    GLX_ARB_multisample

Offline

#8 2007-04-10 09:24:45

XTra KrazzY
Member
Registered: 2007-03-23
Posts: 108

Re: GTK 3D implementation discussion

I think it's GL_ATI_map_object_buffer, but I might be wrong. If so then the only reason that Masscat's GTK 3D implementation isn't working on Evilynux is the brand of his graphics card, and that is NOT fair.

Or maybe Geforce 4 is too old... (its opengl version is still 1.3 but maybe something else is wrong)


As for drawing "off-screen": Draw on the backbuffer.

Last edited by XTra KrazzY (2007-04-10 09:29:15)


If you are reading this signature, you SERIOUSLY need to get a life.

Offline

#9 2007-04-10 12:00:23

SCHUMI-4-EVA
Member
Registered: 2007-03-19
Posts: 97

Re: GTK 3D implementation discussion

Well the 9200 is the ATI series that competed with the GeForce 4 and 5 series so I don't think it's a generation gap...it's probably by the looks of things just that masscat's code is not universal it's just for ATI...but once again I know squat on the topic that's just what it looks like to me, I know a bit about computer's but squat about programming.

Offline

#10 2007-04-10 14:14:44

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

Re: GTK 3D implementation discussion

You need frame buffer objects, it's the fastest actual option, but it might not be supported by an ATI 9200se, as it's quite crappy tongue

Offline

#11 2007-04-10 14:21:37

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

Re: GTK 3D implementation discussion

To my knowledge there is no card/platform specific code and the code runs on my nvidia go7600 based system.

Having had a look at the gtkGLext code, creating an off screen gtkGLext GL pixmap under X Window uses a call to glXCreateGLXPixmap which is part of GLX 1.3 and greater which should be the supported by most Nvidia based cards using a reasonable recent driver.
Under MS Windows it uses a windows only extension that should be supported by all(?) cards/drivers.

I will put some error checking in the code and see if that can find something.

EDIT: my poor 9200SE card sad

EDIT2: Here is the latest update - test3_3d.tar.bz2.
The top screen and bottom screen are separate openGL drawables sharing the single NDS screen texture. By having the screens separate would allow them to be rotated and position independently - allowing things (not implemented) such as placing a gap between the screens and/or rotating the screens, as for Braintraining (this functionality is as currently present in the gtk-glade port).
You can resize the window and the images will scale accordingly.
It also has some error checking to try and catch evilynux's problem.

Last edited by masscat (2007-04-10 18:42:35)

Offline

#12 2007-04-10 22:27:51

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

Re: GTK 3D implementation discussion

masscat wrote:

It also has some error checking to try and catch evilynux's problem.

Houlala, here it is: "openGL error during 3D emulation: invalid operation" appears once and only once.
Since i don't know the infringing command, here are the available ones on my videocard:

direct rendering: Yes
server glx vendor string: NVIDIA Corporation
server glx version string: 1.4
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, 
    GLX_EXT_texture_from_pixmap
client glx vendor string: NVIDIA Corporation
client glx version string: 1.4
client glx extensions:
    GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_SGI_video_sync, 
    GLX_NV_swap_group, GLX_NV_video_out, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGI_swap_control, GLX_NV_float_buffer, GLX_ARB_fbconfig_float, 
    GLX_EXT_fbconfig_packed_float, GLX_EXT_texture_from_pixmap
GLX version: 1.3
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGI_video_sync, GLX_SGI_swap_control, 
    GLX_EXT_texture_from_pixmap, GLX_ARB_get_proc_address
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce4 MX 440-SE/PCI/SSE2
OpenGL version string: 1.5.8 NVIDIA 96.31
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_pixel_buffer_object, 
    GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, 
    GL_ARB_shading_language_100, GL_ARB_texture_compression, 
    GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
    GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3, 
    GL_ARB_texture_mirrored_repeat, GL_ARB_texture_rectangle, 
    GL_ARB_transpose_matrix, GL_ARB_vertex_buffer_object, 
    GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, 
    GL_S3_s3tc, GL_EXT_texture_env_add, GL_EXT_abgr, GL_EXT_bgra, 
    GL_EXT_blend_color, GL_EXT_blend_minmax, GL_EXT_blend_subtract, 
    GL_EXT_clip_volume_hint, GL_EXT_compiled_vertex_array, GL_EXT_Cg_shader, 
    GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
    GL_EXT_gpu_program_parameters, GL_EXT_multi_draw_arrays, 
    GL_EXT_packed_pixels, GL_EXT_paletted_texture, GL_EXT_pixel_buffer_object, 
    GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, 
    GL_EXT_separate_specular_color, GL_EXT_shared_texture_palette, 
    GL_EXT_stencil_wrap, GL_EXT_texture_compression_s3tc, 
    GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, 
    GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod, 
    GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, 
    GL_IBM_rasterpos_clip, GL_IBM_texture_mirrored_repeat, 
    GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_fence, 
    GL_NV_fog_distance, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, 
    GL_NV_pixel_data_range, GL_NV_point_sprite, GL_NV_register_combiners, 
    GL_NV_texgen_reflection, GL_NV_texture_env_combine4, 
    GL_NV_texture_rectangle, GL_NV_vertex_array_range, 
    GL_NV_vertex_array_range2, GL_NV_vertex_program, GL_NV_vertex_program1_1, 
    GL_SGIS_generate_mipmap, GL_SGIS_multitexture, GL_SGIS_texture_lod, 
    GL_SUN_slice_accum
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess

Edit: False alarm, your wave machine doesn't produce that error.

Last edited by evilynux (2007-04-10 22:39:11)

Offline

#13 2007-04-12 12:57:57

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

Re: GTK 3D implementation discussion

The "openGL error during 3D emulation: invalid operation" is because there is currently no checking to ensure that the list of commands forms a valid sequence of openGL calls.

Evilynux, could you try the following couple of hacks/fixes. I have some hope that the first hack maybe the problem so try that first. The second would be a bug in the driver so much less likely.

Hack 1:
Maybe the alpha values are not getting set correctly, here is a hack to ignore them:
Changes are to gtk_3Drender.c.

change line ~2020 (in function gtk_3D_get_line):

comment/delete out the following:

r = (r*a)/255;
g = (g*a)/255;
b = (b*a)/255;

Hack 2:
Another shot in the dark at a fix:
Here is a change to read the pixel data in the same format as stored on the graphics card (possibly). This should not make a difference but you never know.

Changes are to gtk_3Drender.c.

change line ~1151 (in function draw_3D_area):
from

glReadPixels(0,0,256,192,GL_BGRA,GL_UNSIGNED_BYTE,GPU_screen3D);

to

glReadPixels(0,0,256,192,GL_RGBA,GL_UNSIGNED_BYTE,GPU_screen3D);

and change line ~2015 (in function gtk_3D_get_line):
from

u32    r = screen3D[i*4+0],
        g = screen3D[i*4+1],
        b = screen3D[i*4+2],
        a = screen3D[i*4+3];

to

u32    r = screen3D[i*4+2],
        g = screen3D[i*4+1],
        b = screen3D[i*4+0],
        a = screen3D[i*4+3];

Offline

#14 2007-04-12 13:41:10

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

Re: GTK 3D implementation discussion

Using

glReadPixels(0,0,256,192,GL_BGRA,GL_UNSIGNED_BYTE,GPU_screen3D);

is way faster, due to avoiding swizzling when downloading the texture tongue

Offline

#15 2007-04-12 15:01:32

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

Re: GTK 3D implementation discussion

I am confused, although the pixel values are read as GL_BGRA they are processed as RGBA, or am I missing something?

Offline

#16 2007-04-12 15:15:01

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

Re: GTK 3D implementation discussion

Iirc, is how the memory is written, as it's organized in 32bit chunks.

Offline

#17 2007-04-12 18:34:14

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

Re: GTK 3D implementation discussion

I've made some runs in the debugger to see if i could figure something out.
I've added a test just before the alpha part you [masscat] talked about and just after r, g, b and a are assigned from screen3D:
"if( r != 0 || g != 0 || b != 0 || a!= 0 )".

It simply never happens altho we do enter the for loop.

Edit: Still in gtk_3D_get_line, GPU_screen3D[(192-(line%192))*256*4] is always 0.
Edit2: Neither glReadPixels() [with GL_BGRA or GL_RGBA] work i.e. GPU_screen3D is always filled with zeros. I'm starting to wonder if we're after a 64bit specific problem or nvidia geforce4.

Last edited by evilynux (2007-04-12 19:17:23)

Offline

#18 2007-04-12 21:00:55

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

Re: GTK 3D implementation discussion

Not sure what the problem may be.
I am going to do a clean rewrite of the code (ready for committing to cvs). It will have full error checking and the like so that may help uncover something.

To test if pixmaps work you could try compiling the pixmap example from the gtkGLext cvs (pixmap.c).

Compile is with:

gcc -o pixmap_example pixmap.c `pkg-config --cflags --libs gtkglext-1.0`

If it works you will get a shaded red sphere.

Offline

#19 2007-04-12 21:34:16

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

Re: GTK 3D implementation discussion

masscat wrote:

Not sure what the problem may be.
I am going to do a clean rewrite of the code (ready for committing to cvs). It will have full error checking and the like so that may help uncover something.

Alrite, looking forward to it.

masscat wrote:

To test if pixmaps work you could try compiling the pixmap example from the gtkGLext cvs (pixmap.c).

That works perfectly.

Offline

#20 2007-04-12 22:35:24

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

Re: GTK 3D implementation discussion

glReadPixels failing: That's rather easy to fix, it's just setting the buffer to read to FRONT one, as per default is set to BACK buffer, which is bad on double buffer configs if render hasn't finished tongue

Offline

#21 2007-04-12 23:26:05

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

Re: GTK 3D implementation discussion

I think shash may have it, although the off-screen render target is not double buffered.

Evilynux, can you put a call to glFinish() immediately after the call to glFlush() on line ~1223 in the function draw_3D_area in the file gtk_3Drender.c.

Offline

#22 2007-04-13 02:09:41

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

Re: GTK 3D implementation discussion

masscat wrote:

I think shash may have it, although the off-screen render target is not double buffered.

Evilynux, can you put a call to glFinish() immediately after the call to glFlush() on line ~1223 in the function draw_3D_area in the file gtk_3Drender.c.

No change.

FWIW, user P2E in #desmume channel confirmed me it works for him on a GeForce FX5200 in a 32bit environment.
With transparency glitches tho, as you mentionned Masscat.

Last edited by evilynux (2007-04-13 02:11:09)

Offline

#23 2007-04-13 02:14:47

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

Re: GTK 3D implementation discussion

shash wrote:

glReadPixels failing: That's rather easy to fix, it's just setting the buffer to read to FRONT one, as per default is set to BACK buffer, which is bad on double buffer configs if render hasn't finished tongue

Hmm... we're in single buffer mode, could that be the problem?
How are the pixel written?

Offline

#24 2007-04-13 03:22:51

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

Re: GTK 3D implementation discussion

No, as stated here, read buffer is set to front on single buffer configs. And check with glLastError if glReadPixels is failing for some reason. If so, try changing the read format (as your card supports packed pixels, you could even read directly in 16bit, which I didn't as quite a few consumer computers don't support it correctly).

As I don't have linux, neither I'm going to install it anytime soon (too busy), that's as much as I can help.

Offline

#25 2007-04-13 16:01:25

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

Re: GTK 3D implementation discussion

Unfortunatly, glReadPixels() doesn't fail...

I was asking how the information was written to the framebuffer as i'm more and more suspecting that it's a 64bit issue. It seems i'm the only one for whom it doesn't work.

Edit: Using double buffering, reading from the front buffer and dumping the read buffer show a not null first line. But that's it. The rest of the buffer is null. (I couldn't get those results with single buffer).

Last edited by evilynux (2007-04-13 18:32:06)

Offline

Board footer

Powered by FluxBB