File packer test.

[MichaelW]

Puzzling, what kind of gfx card do you have ?

The Windows 98 SE system has an old Rage Pro Turbo, the drivers are the last version ATI produced, and ATOGLRP9.DLL is an ATI component. By including OpenGL support ATI was pushing the limits on these drivers, so I doubt that this problem is worth solving. The Windows 2000 SP4 system, where tearing in full-screen mode is the only problem, has a Matrox G200 with the default Windows 2000 drivers.

[hitchhikr]

Try with this one instead.

The point is only about the packer anyway, i just want to know if it's able to run files correctly,

I had some troubles on ATI too (as usual) because their implementation of wglCreateContext located in atioglxx.dll is looking inside the structure of the PE file for some odd reasons and crashes if the IID referenced in the PE header isn't valid anymore (so the depacking routine must be preserved) etc.

I don't think ATI ever heard about quality insurance.

Thanks for the testing, btw.

[attachment deleted by admin]

[MichaelW]

The new version behaves just like the older one on the Windows 2000 system. On the Windows 98 SE system it works OK in a window, but full screen, it displays a black screen and terminates.

[hitchhikr]

The matrox probably doesn't have WGL_EXT_swap_control extension so there's no way to wait for the vblank interrupt, i'm surprised it can't animate a simple cube in one frame, did you try some other ogl animations with it ? Try the stuff present here: http://nehe.gamedev.net/.

Check this attached one, if it works that means the rage pro isn't able to display 800x600x32 screens.

[attachment deleted by admin]

[MichaelW]

Duh... I just realized that I left the desktop color depth for the Windows 98 SE, Rage Pro Turbo, K5-112 system set to 16bpp after the Q2 tests. With the color depth set to 16bpp, neither version will run full-screen, but both display with smooth motion and no tearing in a window. Resetting the color depth to 32bpp, both of the last two versions run in a window or full screen, and look essentially the same, with jumpy motion and updates that are obviously taking more than one vertical frame.

On the Windows 2000, G200, P3-500 system, both versions look the same, with intermittent tearing in the faces in full-screen mode, and no tearing in a window. The behavior and appearance does not seem to vary with the desktop color depth, whether 16 or 32bpp. Why does the lack of vrsync affect the animation when at full-screen but not in a window?

I didn't have time to try the other amimations.

[hitchhikr]

Never heard about cards/drivers with config options to force the display into one particular resolution. I use ChangeDisplaySettings to switch into fullscreen, btw.

I think you have troubles with the drivers, even a simple tnt is able to animate an ogkl cube within the frame, i remember i had some major slowdown issues with my ati card concerning the agp port, i had to install a driver for the motherboard due to this.

I think in the window mode there's some bitblit to copy from the backbuffer onto the screen while in fullscreen mode it relies on pages flipping, but it's just a guess.

These cards are very old devices anyway.

[hutch--]

Hitch,

It runs fine on my win2k dev box that uses a 128 meg Leadtek video card of about 7 or 8 months ago. Basically the display in either full screen or in a window is a slow rotating cube.

[MichaelW]

Never heard about cards/drivers with config options to force the display into one particular resolution.

I'm using the Settings tab in the Windows Display Properties dialog.

[hitchhikr]

What i'm saying is that the resolution used for the desktop shouldn't override a call to ChangeDisplaySettings() to obtain a different one if it's handled by the gfx card.

For example, if the resolution of the desktop is 800x600x16 and the card handles 800x600x32, a program can obtain that second resolution without any problem but it seems that you have to switch to 800x600x32 before starting a program asking for such resolution and that weird.

[Mark Jones]

Nifty! The first time I ran it, windowed and fullscreen worked fine. Fullscreen took a few seconds to start displaying the cube. Then when it was terminated, all the open windows were shifted down+right about 50 pixels. Not a problem, but it would be nice if it didn't do that. :) I tried some of the newer versions, and now the mouse disappears inside the client area of the windowed version. WinXP.SP1 & GeForce FX5600 ultra.

Any chance of sharing the file packer source code? :bg

[hitchhikr]

all the open windows were shifted down+right about 50 pixels.

You mean it doesn't restore the original screen resolution ?

tried some of the newer versions, and now the mouse disappears inside the client area of the windowed version.

Yeah, the mouse is supposed to disappear.

It uses the LZMA algorithm.

[Mark Jones]

all the open windows were shifted down+right about 50 pixels.

You mean it doesn't restore the original screen resolution ?

No, the resolution switching is fine. Just the positions of any previously open windows are shifted down and right after closing cube.exe.

tried some of the newer versions, and now the mouse disappears inside the client area of the windowed version.

Yeah, the mouse is supposed to disappear.

Oh, okay.

It uses the LZMA algorithm.

That's a start I guess. :)

[thomasantony]

Hi,
It works okay on my Win98SE with my poor onboard gfx card. The BIOS says it has only 1 MEG video RAM but I think it shares more with the system RAM.

Thomas

[Polizei]

Aloha !! ;)
Windows XP Professional No Service Packs : workz
Windows XP Professional Service Pack 2 : workz
Windows XP Professional Media Center Edtion : workz ;)

All this Windows'es I have installed on PCs in school, where I`m a sysadmin

<Edited on May 21st. Y2K5>
btw, won't you show us the the exe packer, not the packed exe ;)) so we will can make some real tests ...
I`ve written a PEPacker too, and I have had some problems on NT-based operating systems...
I mean problems when packing the exe