Help needed with debugging on Microsoft Vista / Computer Science / Forums

Forums

4hv.org :: Forums :: Computer Science

« Previous topic | Next topic »

Help needed with debugging on Microsoft Vista

Move Thread

LAN_403

Bjørn

Tue Feb 20 2007, 08:15AM

Registered Member #27 Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058

I don't have Vista on any of my computers and one person has reported that Head-On was not running smoothly on Vista.

If you have Vista it would be very helpful if you downloaded the game and gave it a quick test and attach the resulting "gameData/logFile.txt" with any comments about how it worked. I would be interested in anything that does not seem quite right.

If you don't want to make the logfile public you can send it to **link**

http://www.sciencezero.org/headon/headon.zip

J. Aaron Holmes

Tue Feb 20 2007, 05:37PM

Registered Member #477 Joined: Tue Jun 20 2006, 11:51PM
Location: Seattle, WA
Posts: 546

Runs nice and smooth for me. Even when I revert to Standard VGA and disable all hardware acceleration via DxDiag. Machine is a Dell OptiPlex GX240 - P4 2.2GHz - 1Gb RAM.

The only minor thing I notice is that when I switch between levels on the level-select menu, the image of the level I'm leaving is momentarily displayed using the palette of the next level, causing one...maybe two...frames to be drawn with the wrong palette (level image is all psychadelic-looking for one split second).

Did the person complaining about this upgrade their existing computer to Vista, or buy a new machine? Different video adapters seem to object to different video memory access patterns, sometimes in unexpectedly extreme ways. Try doing ScrollRect() on a video memory-resident DC gotten from IDirect3DSurface9::GetDC() on an ATI Radeon 9xxx and see what I mean (although generally any reading from video memory is criminal--as is Locking and poking bytes into video memory one at a time, unless you're just composing a palette of bitmaps that you plan on handing to CopyRects() later or using as textures, etc.) Don't know what API you're using and how you're managing your buffers, etc., though. Unless he/she upgraded their existing machine to Vista, my immediate though is that the video adapter or driver is probably to blame.

Regards,
Aaron, N7OE

Bjørn

Tue Feb 20 2007, 06:48PM

Registered Member #27 Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058

Thanks for the help, that is good news.

I use The DirectDraw lock functions to lock the surfaces and write directly to the backbuffer in the graphics card. It was the only way of making it work on slow Pentium computers on all graphics cards at full framerate.

Some newer graphics cards have problems when I update palette and it takes several frames before they get properly updated. The code supports 32 bit pixels so I might fix it by using true colour on computers that seems to have a lot of video memory.

J. Aaron Holmes

Tue Feb 20 2007, 07:05PM

Registered Member #477 Joined: Tue Jun 20 2006, 11:51PM
Location: Seattle, WA
Posts: 546

Are you locking the buffer in video memory, or locking a system memory buffer, then blitting to your backbuffer? If you have enough memory, the latter approach is usually the better performer in my experience, since despite the fact that you're basically writing the pixel values twice, the "write combining" or DMA into video memory from system memory during blit is fast enough to more than make up for it in the end. Curiously, perhaps as a result of the latter method being advocated on MSDN and in other places in recent years (or perhaps for completely different reasons), the performance obtained by directly locking a buffer in video memory appears to have actually gone down in recent years. You'll note that, in Direct3D 9 (maybe 8 too), you have to specially ask for a video memory surface to be lockable, since lockability impedes performance.

Regards,
Aaron, N7OE

Bjørn

Tue Feb 20 2007, 08:14PM

Registered Member #27 Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058

I am locking the buffer in video memory, on many slow Pentium computers with a 2MB graphics cards it is not possible to blit from system memory to video memory at full framerate. On ISA cards it would be down to 1 fps.

J. Aaron Holmes

Tue Feb 20 2007, 09:57PM

Registered Member #477 Joined: Tue Jun 20 2006, 11:51PM
Location: Seattle, WA
Posts: 546

1fps does indeed suck. But who actually uses that hardware anymore?

I guess if this is old code you wrote "back in the day", then there's no cause for changing it unless the performance issues become the norm. Still, I'm consistently impressed by how seemingly innocent things can cause performance to tank on even the most expensive modern graphics hardware!

A while back, I wrote a replacement graphics engine for the Nester NES emulator that could do 60fps on a P90 (I only knew this because I rescued a P90 from the dumpster just to run the benchmark!) I never bothered to integrate my new graphics engine with the public source code, however, because by the time I had all the kinks worked out, PIII 600's were "the norm", and even the crummiest code could do 60fps on semi-modern hardware. I think, by that time, somebody had already written one in Visual Basic!

Regards,
Aaron, N7OE

...

Tue Feb 20 2007, 11:24PM

Registered Member #56 Joined: Thu Feb 09 2006, 05:02AM
Location: Southern Califorina, USA
Posts: 2445

She seemed to run just fine under vista buisness running in a vmware virtual machine hosted by fedora running on a pentium M at 1.3ghz and no accelerated graphics

In any case, attached is the log file...
]1172013836_56_FT20963_logfile.txt[/file]

btw, if it would help, I can give you the vista image for vmware (it always thinks it is on the same computer, so it never looses the activation)... pm me

Bjørn

Wed Feb 21 2007, 07:14AM

Registered Member #27 Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058

The code is fairly old but 90% of the downloads are from countries where there still are some low end Pentium computers and the odd 486 in use so I would not want to change the code except make it run in a different way on modern computers.

Bjørn

Sat Nov 17 2007, 02:09PM

Registered Member #27 Joined: Fri Feb 03 2006, 02:20AM
Location: Hyperborea
Posts: 2058

The problem was simple to fix. DDEnumCallbackEx often returns several DirectDraw devices, only the first one seems to work well with 8 bit video modes. At least on NVIDIA cards.

I originally used the second device because that is what worked on Matrox Millennium once upon a time. I miss those cards, not so much because of the hardware but because if there were any problems they would respond to e-mail and it was actually possible to get in touch with the people responsible.

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob