Compatibility test for compiled Object3Ds

[EgonOlsen]

Laptop:  WindowsXP SP2 Intel Core2 2.00GHz 2.00GB Ram NVIDIA GeForce Go 7950 GTX fps:Won't run

On the laptop it gets all the way until the output starts the fps, but the car doesn't appear. Then I get the WindowsXP this programs has screwed up and do you want to send a report dialog. The previous version ran on the laptop.

Damn...i had a similar problem myself, where compiling the display lists (which is what happens in that stage) causes a VM crash from time to time when using a larger batch size than 2000-something (which is actually quite small). I've moved that operation to another stage now. For me, it fixes the problem. Maybe you could give this fixed version another try on the laptop!? If it still doesn't work: I've included various batch-files that start with 1000, 2000, 4000, 6000 and 8000 as batch size in addition. Maybe on of them works?

BTW: Closing the windows now works too.

[JavaMan]

I tried out all the versions. The problem begins with the runme_6000. The strange thing is though that I ran the program with VM 9000. Sometimes that would work, and other times it wouldn't work: I get the error dialog. Also, I get the same random work-doesn't work issue with the runme_6000.

Maybe you have already thought of this, but I noticed that the print out prints the first fps value and then states that all the objects have been compiled. I am wondering if jpct tries to draw the car before it is completely compiled, and sometimes this doesn't work out? Maybe some threading issue, since the problem is so random. Just a thought.

[EgonOlsen]

The interleaved print out of fps and "compiled..." is fine. It may be a threading issue anyway. The demo uses multi-threading in two ways. The first way is in the renderer itself. The second part is when calculating normals (which should be not related to this issue) and when filling the buffers to render. I've uploaded a new version (again... ) and a different one. The new version still uses multi-threading for the renderer but not any longer for the filler. The second one (http://www.jpct.net/download/beta/car_nt.exe) doesn't use MT at all. Maybe one of those will work?

BTW: I was able to verify the occasional crashes on my machine. They seem to be gone with both new versions, but that's just me...

Edit: And thank you very much for your patience...

Edit 2: This really annoys me. The problem (at least the crash that i get on my machines from time to time) is somehow related to the filling. What i call "filling" here, is copying an Object3D's mesh data into java.nio.FloatBuffer...nothing too special at all. This used to happen in multiple threads on multi-core machines to speed it up. The filling itself went fine (at least without errors) but rendering the result afterwards caused a crash sometimes. The crashes got more likely the larger the FloatBuffers were. With a batch size of 50000, i got a crash for sure. With 10000, it was like a 20% chance. I've ensured that each object is compiled exactly once, i.e. not two threads are working on the same buffers. There is nothing static in the structure that holds the buffers, all buffers are filled and ready to render when starting to compile the display lists from them (which is the step that caused the crashes). So the only option left that could cause these crashes is bad data in the buffers! But i've no f***ing idea what causes this. It makes no sense at all. Four threads working on four completely different sets of data with no interaction between them...how could this cause bad data in some of them? If i wouldn't know it better (i don't, but i've the feeling that i should...), i would think that this is a problem with java.nio, not with my code.
Anyway, i've removed the multi-threaded code from this section now and it seems to work. At least i can't reproduce the crashes i got before anymore.

[JavaMan]

Ok, I downloaded it earlier this morning, but didn't get a chance to try it out. I will re-download the car_nt and the car.exe files and try them out, and let you know what happens.

Until, then I did a search and I found this old topic in the Sun's forums. I didn't read the whole thing( it was rather long), but the issue was over how nio is uses the native os to perform the work:might help. http://forums.sun.com/thread.jspa?threadID=607775

[.jayderyu]

What I have

CPU(cheap dual core)
775LGA
Intel Pentium D 2.80 Dual Core(MMX, SSE, SSE3, EM64T)

Ram DDR2(266.6MHz, 1.5gb)

ATI Radeon HD 3400
512MB ram
Internal DAC(400mhz)

Windows XP sp3, DX9.0c

FPS: 70-74

[JavaMan]

Oh yah! I got to test out the new version of the car.exe and car_nt.exe,  they both work just fine! I am getting 134-137fps. Also, the laptop has a Centrino Duo processor and 1GB of ram not 2.

One little note. Sometimes the OpenGL window is just slightly larger than the screen instead of 800*600. In this window though, jpct only renders to what appears to be 800*600 in the bottom left corner of the window.

[EgonOlsen]

Oh yah! I got to test out the new version of the car.exe and car_nt.exe,  they both work just fine! I am getting 134-137fps. Also, the laptop has a Centrino Duo processor and 1GB of ram not 2.

You were a bit lucky with the car.exe, because it still has the problem (somewhat relaxed, but it's there). BUT: I finally found the source! It's not in jPCT's code, it's in the demo itself. The demo uses LWJGL to poll the keyboard and to determine the state of the Display. Because the renderer of car.exe is running in another thread, there seems to be a problem when compiling the display lists in one thread while querying the display and/or keyboard in another. The solution is to move that stuff into the methods that the IPaintListerner Interface provides because they will be called in the same thread. This one took me a few days, but if i would just have followed my own advises, i would have noticed this earlier...

One little note. Sometimes the OpenGL window is just slightly larger than the screen instead of 800*600. In this window though, jpct only renders to what appears to be 800*600 in the bottom left corner of the window.

Nothing i can do about that. I'm just asking LWJGL for the windows. Why it does this strange thing...i don't know.

However, i thank you very much for testing. It really helped me to narrow it down.

[JavaMan]

You were a bit lucky with the car.exe, because it still has the problem (somewhat relaxed, but it's there). BUT: I finally found the source! It's not in jPCT's code, it's in the demo itself. The demo uses LWJGL to poll the keyboard and to determine the state of the Display. Because the renderer of car.exe is running in another thread, there seems to be a problem when compiling the display lists in one thread while querying the display and/or keyboard in another. The solution is to move that stuff into the methods that the IPaintListerner Interface provides because they will be called in the same thread. This one took me a few days, but if i would just have followed my own advises, i would have noticed this earlier... Wink

Thats great you figured it out!

However, i thank you very much for testing. It really helped me to narrow it down.

Hey, I am glad I was able to help a little for the new feature. 

[raft]

all the tests run ok on my crap intel 915 on board chipset. fps are 3-7

i will run them on a decent desktop as soon as i can..

[Melssj5]

It ran at 13 fps on my centrino 1.6, 1GB ram, ATI X600, Windows XP - jre1.6.0_12

[C3R14L.K1L4]

At my desktop got ~243 FPS.



Specifications:

CPU Type   Mobile AMD Turion 64 ML-34, 2289 MHz (9 x 254) 
   Motherboard Name   Asus K8N4-E Deluxe (3 PCI, 3 PCI-E x1, 1 PCI-E x16, 3 DDR DIMM, Audio, Gigabit LAN, IEEE-1394) 
   Motherboard Chipset   nVIDIA nForce4-4X, AMD Hammer 
   System Memory   2048 MB (PC3200 DDR SDRAM)

Video Adapter   Asus EN8600GT  (512 MB)
   GPU Code Name   G84GT (PCI Express 1.0 x16 10DE / 0402, Rev A2) 
   GPU Clock (Geometric Domain)   648 MHz (original: 540 MHz, overclock: 20%) 
   GPU Clock (Shader Domain)   1404 MHz (original: 1188 MHz, overclock: 18%) 
   Memory Clock   837 MHz (original: 700 MHz, overclock: 20%) 

OS: Microsoft Windows XP Professional 32-bit SP3

At my laptop got ~36 fps.

Specs:

Operating System   Microsoft Windows 7 Ultimate
CPU Type   DualCore AMD Athlon X2 QL-62, 2000 MHz (10 x 200)
Motherboard Name   Toshiba Satellite L300D
Motherboard Chipset   AMD M780V, AMD K11
System Memory   2816 MB  (DDR2-800 Registered DDR2 SDRAM)
DIMM1: Samsung M4 70T2864QZ3-CF7   1 GB DDR2-800 DDR2 SDRAM  (6-6-6-18 @ 400 MHz)  (5-5-5-15 @ 333 MHz)  (4-4-4-12 @ 266 MHz)
DIMM3: Samsung M4 70T5663QZ3-CF7   2 GB DDR2-800 DDR2 SDRAM  (6-6-6-18 @ 400 MHz)  (5-5-5-15 @ 333 MHz)  (4-4-4-12 @ 266 MHz)
Video Adapter   ATI Radeon 3100 Graphics  (256 MB)

I hope I didn't scare anyone with this...

[EgonOlsen]

I hope I didn't scare anyone with this...

I don't think so. Why should you...

[C3R14L.K1L4]

Just because you requested "Preferably with frame rate and system configuration" and I detailed it

At my sister's PC, GF7600GS + 1.5GB DDR400 + VIA K8M800 + Sempron 3100+ ~ 76 fps.

[EgonOlsen]

Just because you requested "Preferably with frame rate and system configuration" and I detailed it

That's cool...i like that. Being a hardware freak myself, i really like detailed specs.