Graphics corruption on real hardware

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
Post Reply
b0b
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 18
Joined: Thu Mar 15, 2007 12:04 pm

Graphics corruption on real hardware

Post by b0b » Sun Apr 29, 2018 6:02 am

Hi,

I'm writing a little game for the DC and it is coming along nicely. the physics and input systems seems to be working fine, but I'm having problems on the graphics side.

The whole thing is in 3d. I'm using the direct render interface in KOS, so no KGL. It does run and producing correct output in reicast, redream and lxdream emulators, but I'm only getting garbage output on real hardware.

there are two separate processing paths implemented - one for z-near-clipping enabled and one without. the output stays broken if i disable the "clipping mode enabled" path completely, so the clipped polys simply are skipped. I see that the physics/input code is working on real hardware, "only" the graphics are wrong.


What could be wrong here? data alignment to the pvr? I am using the pvr_dr_init, pvr_dr_target, pvr_dr_commit (with pvr_vertex_t) stuff only for sending the vertices to the pvr. so it is not done through custom assembly or something. at least not now ;)
vertices processed in tristrips batches. The lighting is done through a couple of assembly functions, but i doubt things go wrong here
because i see the lighting actually working (producing the correct vertex colors) on real hardware. and even if i disable lighting the graphics stay corrupted.
Kannagi
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 19
Joined: Mon Jul 28, 2014 3:24 pm

Re: Graphics corruption on real hardware

Post by Kannagi » Mon Apr 30, 2018 7:02 am

I advise you to use lxdream for testing, even if it does not work very well for commercial games, it is strangely enough faithful to the real machine in terms of speed and bug.

Nevertheless no emulator emulates the cache memory (whether on Dreamcast or otherwise), so if you have data sent using a DMA for example, think either to flush your data, or to use the memory Uncached (P2).

The other point the emulators never emulates the speed of drawing, which does not create any conflict on emulator, your graphics bug can be due to a conflict of vertex buffer.

And the last strange bug that I never really understood and the initialization of the addresses of the different buffer, I had graphic bug when I only changed their addresses :/
In function pvr_allocate_buffers.

Of course, the best is a source code or a photo of your bug, it would be useful to know where your bug comes from :)
b0b
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 18
Joined: Thu Mar 15, 2007 12:04 pm

Re: Graphics corruption on real hardware

Post by b0b » Mon Apr 30, 2018 9:28 am

thats the same experience i've made - lxdream is nearly unusable for commercial games, but it somehow works best for homebrewed stuff.
I'm aware that the dreamcast emulators don't emulate the hardware properly and use many workarounds for performance.


there is an elf file attached (game data is compiled in, romdisk), runs in lxdream. if converted to cdi it also runs in redream and reicast. but does not run on real hardware. i mean it boots, you see it runs, but graphics are garbage...
i can post some code later, but i really need to clean up the renderer file as there are a lot unused functions, but only a handful are used. same goes for the physics code ;)

how the game loop works right now is as following:

load data
run loop:

- update physics
- set properties (matrices etc, op poly drawing) for 3d perspective
- draw all op polys
- set list to tr polys
- draw particles (smoke effects)
- set up for 2d (keep tr poly list)
- draw hud


a little specific for actual drawing stuff:
all models are split to "material groups". each group has an material (opengl style) attached and a vertex and index array.
vertices in the array are as following
float x,y,z
norm x,y,z
texcoord u,v
-> 32 bytes
the index array are simply unsigned shorts as triangle strips, but ushort max value (65535) is used as "primitive restart". (works on most opengl implementations, linux here, and the vertex format is opengl friendly, on dc no opengl ís used though)

each material group vertex buffer is copied into a temporary buffer first using s-queues.
the copy has the vertex format
float x,y,z,u
float nx,ny,nz,v
the u-coord changes position, each vert 32 bytes

lighting is done for the (up to) 32 verts.
lighting functions are assembly, the before mentioned format allows it to do everything lighting related in 64bit FP mode without switching (1x fschg at the beginning and 1x at the end of the function)
for each light the float a,r,g,b values are accumulated and saved in a second temporary buffer. after proccessing each light the values of this buffer are packed to int32 and saved to original vertex data replacing one of the normal values (so normal.x becomes argb color...)
lighting is an implementation of opengls fixed pipeline. the separate functions would be for directional light with specular, dir light without specular, point light with and without specular... (spotlight not implemented yet)

after lighting the vertex format is
float x,y,z,u, v, color (packed as int32), unused, unused
(still 32 bytes)


copying is done in batches of 32 verts.

copy 32 verts, light 32 verts, copy next 32 verts, light 32 verts etc

if all material group vertices are copied and lighting applied - draw stuff
z-near clipping is activated before based on bounding box intersecting the near plane. the clipping implementation isn't the most effective ( it splits to triangles instead of tristrips, i've tried another implementation, but i still haven't figured out the occasional winding order switching there :/ )


drawing is done with the pvr kos direct render functions, no assembly here. no dma either (I havent tested dma yet). but each vertex is 32 bytes everytime.



attachment:
Attachments
race.zip
(1.52 MiB) Downloaded 29 times
Kannagi
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 19
Joined: Mon Jul 28, 2014 3:24 pm

Re: Graphics corruption on real hardware

Post by Kannagi » Mon Apr 30, 2018 10:48 am

The demo hurts the eyes on real console ^^'
I have never used the lib pvr for rendering (just looked at its source code for creating the context and initializing the DC).
I never had this kind of bug during my tests, the lib pvr uses semaphores so it will have avoided this kind of bug.
You should tested if you use the lib correctly on the display of a model, say that the dreamcast asks to send your data correctly in the VRAM (the emulator is less demanding).

Or use my lib (but I'm aware that it's not really usable now).

The demo seems well on emulator ;)
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5365
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: Graphics corruption on real hardware

Post by BlueCrab » Mon Apr 30, 2018 9:10 pm

Seeing the source code would probably make it a lot easier to try to figure out what's going on. Unfortunately, without seeing the code, I can't even hazard a guess as to the issue...
b0b
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 18
Joined: Thu Mar 15, 2007 12:04 pm

Re: Graphics corruption on real hardware

Post by b0b » Fri May 04, 2018 3:35 pm

huh...


i am cleaning up my rendering source code. removing unused functions, static variables and so on...

and there is one big unused function - if i delete it or comment it - everything breaks on emulator too. it compiles and links without it, but graphics breaks. if i leave it in - it works on emulator. it's c code, no assembly

WTF XD
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5365
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: Graphics corruption on real hardware

Post by BlueCrab » Fri May 04, 2018 11:17 pm

That is... certainly strange.

Often when there are things that break on real hardware but not on emulators, it can be traced back to things where the emulator either doesn't bother with emulating (caches) or where it does so poorly. But, that certainly doesn't sound like it is the case there with that description. Maybe you've run into some kind of weird compiler/optimization bug?
b0b
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 18
Joined: Thu Mar 15, 2007 12:04 pm

Re: Graphics corruption on real hardware

Post by b0b » Sat May 05, 2018 4:22 am

BlueCrab wrote:
Fri May 04, 2018 11:17 pm
Maybe you've run into some kind of weird compiler/optimization bug?

most likely. i do know my znear-clipping code broke before when compiled with -O3, but looked fine with -O2
-.-
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5365
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Contact:

Re: Graphics corruption on real hardware

Post by BlueCrab » Sat May 05, 2018 8:41 am

SuperH isn't exactly a target that is prioritized by the GCC developers, and often times aggressive optimizations produce broken code because of that...

What version of GCC are you using and what flags were you passing to it related to optimization?
Kannagi
DCEmu Fast Newbie
DCEmu Fast Newbie
Posts: 19
Joined: Mon Jul 28, 2014 3:24 pm

Re: Graphics corruption on real hardware

Post by Kannagi » Sat May 05, 2018 9:16 am

I assure you, I have the same concern, I had to put the main function with the -O0 option for my code to work !
Post Reply