Jornada 525, Make it worke?

[Narnia]

The upper half of my screen is blank? - Else is working! Please tell me WHY???

[R0B]

The upper half is the main game, the lower half is the vpad.  I thought you would get an error saying missing gfx.wad or something.  So make sure you have pak0.pak and that it isn't currupted at all.  BTW, how can you consider everything else to be working, if 90% of the game doesn't.  I'd say, give us some more info.

[haborn]

Well it's like everything else that has somthing to do with the display on 525. it's the 256 color issue.<br><br>I found an mediaplayer for the 525 on hp homepage which refuses to go fullscreen all you get is a lot graphic junk, The display (driver or hardware)on the 525 is shit !<br><br>I read somewhere tha gx.dll should recall the information about the screen and graphical hardware ! <br><br>what does it recall ?

[R0B]

This is what I have read, so if I am wrong, I am very sorry.  What gx.dll does (and only if the function is called (and I am fairly certain that it is not called in PQ)), is return a 1 or 0 if the display hardware is a "normal" or if it is "not normal" (but maybe not in that order).  Although if it says it works with a 525, then it should work.  It is also possible that the way quake rights to the screen is using a higher color depth (yet again, I haven't looked or found a need to), it would be pretty easy to change if that's all it was (as long as you have an idea of what you are doing.  Just remeber 256 uses 1 byte, and higher resolutions use more, making the pixels plotted farther apart.

[Dan East]

Does the 525 have a color display?<br><br>Dan East

[Moose or Chuck]

Yes, all it is is a 16MB Jornada 545. Except I think the color depth is lower than the 545.

[TBone]

Sounds like a lot of the same deal as the monochrome iPAQ. An 8 bit display does not mesh well with programs like PocketQuake that natively write in 16 bits. You'd have to convert it the same way I did, although you'd have an easier job since you're working with whole bytes.<br><br>Tell you what. Buy me the hardware and I'll do it for you. <grin>

[Haborn]

So it is on the whishlist ?<br><br>Sounds like it will go a little bit faster ?<br><br>1 byte/Pixel is it what they call "chunky pixels"<br><br>

[TBone]

I don't think it'll happen unless someone with a 525 gets the source code and makes it work. If I had one, I'd give it a shot, but as it is I'd be working blind. That's why I said I'd need the hardware.<br><br>On the other hand, the code really isn't that difficult. The only thing that's proprietary is the video code, and since you're dealing in whole bytes it wouldn't be hard to alter. The compiler is free, unless you get it on CD and then you're only paying for shipping. I'd advise waiting until the new source (with the mono iPAQ changes) goes up and adapting its approach, since it already works with 8-bits at a time instead of 16. If you need any help, feel free to use these forums (I got a lot of help from everyone here), but (speaking for myself) unless the programmer has the device it won't get ported. It's kind of up to you.<br><br>And will it run faster? Probably not. The copying of the video buffer from Quake-format to device-format is really a very, very small chunk of the rendering pipeline, no matter how much you tack onto it. If it were bigger, mine would run faster since it writes two pixels in the same loop the color devices write one, but if anything my performance is a little lower (I don't trust overclocking much, and there are some extra steps you have to take to convert to greyscale).