directx? error on running of worldeditor 32

[nicholasneko]

i installed the newest release of directx 9c just to make sure that wasn't the issue as far as i can tell, each time i try to run the program i get this error and i did not see anything about it on the huge help and instruction page for the program but wow its a nice page.. anyway heres a screen shot and text of the error.


DDERR_INVALIDPIXELFORMAT
The pixel format was invalid as specified

File: .\Directx.cpp
Line: 584

[DarkCheetah]

i got the same trouble :/ did u already fixed? or u stil not know?

[Arcalane]

This was posted TWO YEARS AGO, IN 2006! Jeez man, check the dates before responding!

[lav_coyote25]

This was posted TWO YEARS AGO, IN 2006! Jeez man, check the dates before responding!

so people may be having the same problem STILL THIS YEAR.  so hows about fixing the problem instead of saying jeez, man....  ;D and if your unable to fix it - dont comment. please.

[Rman Virgil]

i got the same trouble :/ did u already fixed? or u stil not know?

* Did you update your GFX accelerator driver ?

* If you did and you still get the same error mess... your outta luck ?

* Unless you can get a card that supports the 8bit PAL protocol that 32EW is useing...

* The other solution is modifying the 32 EW source code to make it comply with your accelerator.. but this last is impossible because the source for 32 EW was lost in a system failure on the coders comp.

* Actually, come to think of it, there may be another solution for you... something of a long-shot ... but worth a last resort before giving up.

* The tertiles that 32EW uses are 24 bit .pngs...

* You might try  converting the tertiles to 16- bit .pngs and see if that works....

* But first make sure your GFX Accelerator driver is updated and that this does NOT solve the problem ... then do the 24  > 16-bit .png conversion.

* If none of the above works then it falls back to the code level modification I mentioned that cannot be done... or a new GFX Card.

* Good luck.

- RV

[Buginator]

* Did you update your GFX accelerator driver ?

* If you did and you still get the same error mess... your outta luck ?

* Unless you can get a card that supports the 8bit PAL protocol that 32EW is useing...

* The other solution is modifying the 32 EW source code to make it comply with your accelerator.. but this last is impossible because the source for 32 EW was lost in a system failure on the coders comp.

* Actually, come to think of it, there may be another solution for you... something of a long-shot ... but worth a last resort before giving up.

* The tertiles that 32EW uses are 24 bit .pngs...

* You might try  converting the tertiles to 16- bit .pngs and see if that works....

* But first make sure your GFX Accelerator driver is updated and that this does NOT solve the problem ... then do the 24  > 16-bit .png conversion.

* If none of the above works then it falls back to the code level modification I mentioned that cannot be done... or a new GFX Card.

* Good luck.

- RV

Are you saying EW32 is using 8 bit palletized bitmaps ?
I don't think that is the case.

Usually, for that error, people are not in 32bit mode on the desktop, and are using 16bit.
The next fault is using either intel or S3 gfx chipsets/cards.

However, if people don't even say what hardware they are using, it is pretty hard to help out.

[Rman Virgil]

Are you saying EW32 is using 8 bit palletized bitmaps ?
I don't think that is the case.

Usually, for that error, people are not in 32bit mode on the desktop, and are using 16bit.
The next fault is using either intel or S3 gfx chipsets/cards.

However, if people don't even say what hardware they are using, it is pretty hard to help out.

* I got this same on my comp. I guess Dark Cheetah didn't care for my answer here so posted in an other thread today. Sharp.  Oh well.

* EW uses 1555 ARGB to store 8bit PAL......... My GFX card uses the more modern 565 RGB (not supporting A1R5B5G5).... when the 8-bit PAL was changed in EW to 565 RGB the problem went away. It took over a week to diagnose and remedy.

* But hey.... to each his own. 

- RV

[Buginator]

* I got this same on my comp. I guess Dark Cheetah didn't care for my answer here so posted in an other thread today. Sharp.  Oh well.

* EW uses 1555 ARGB to store 8bit PAL......... My GFX card uses the more modern 565 RGB (not supporting A1R5B5G5).... when the 8-bit PAL was changed in EW to 565 RGB the problem went away. It took over a week to diagnose and remedy.

* But hey.... to each his own. 

- RV

The last look I had for EW32, it used 888 mode, and everything is true color.  Shame we don't have this source.  On a interesting note, if you compare .exes you will see not much of the core routines have been changed.
Anyway 555 mode is 16bit, as is 565 (1+5+5+5 = 16).  That is why I wondered where do you get 8bit palletized from?  Or are you talking about the bitmaps the old version supported?

Which hardware do you have anyway ?

[Rman Virgil]

The last look I had for EW32, it used 888 mode, and everything is true color.  Shame we don't have this source.  On a interesting note, if you compare .exes you will see not much of the core routines have been changed.
Anyway 555 mode is 16bit, as is 565 (1+5+5+5 = 16).  That is why I wondered where do you get 8bit palletized from?  Or are you talking about the bitmaps the old version supported?

Which hardware do you have anyway ?

* Sorry Bug, I should have given you more detailed  information.

* I have 3 running versions of EW.

* Pumpkin's original EW which I started useing when it was released in June '99 and never had any probs with.

* Qalmy's "32EW" (the source lost) which I had some minor issues with because Qalmy never finished it the UI routines. Those issues I sorted through with Coyote & Watermellon a long time ago and have used it since with no problems.

* The 3rd version of EW that I'm useing was built outta the Pumpkin Source by Remus. This version supports a 32bit Desk Top and uses 24 bit .pcx instead of 24bit .pngs (there were very good reasons for moving away from .pngs that I'm not gonna get into here). This is the version of EW were I encountered the PAL (DX) issue with my card on my Toshiba SAT duo-core Centrino LT (w/integrated Intel GFX accelerator). That problem was eliminated when Remus made the changes I described to the new EW .exe he coded. I no longer have the prob and can run all versions of EW flawlessly. Right now I am only useing Remus's EW because I'm working on the new Campaign maps for 2200 which run our data set and binary.

- Cheers, RV

[Buginator]

* Sorry Bug, I should have given you more detailed  information.

* I have 3 running versions of EW.

* Pumpkin's original EW which I started useing when it was released in June '99 and never had any probs with.

* Qalmy's "32EW" (the source lost) which I had some minor issues with because Qalmy never finished it the UI routines. Those issues I sorted through with Coyote & Watermellon a long time ago and have used it since with no problems.

* The 3rd version of EW that I'm useing was built outta the Pumpkin Source by Remus. This version supports a 32bit Desk Top and uses 24 bit .pcx instead of 24bit .pngs (there were very good reasons for moving away from .pngs that I'm not gonna get into here). This is the version of EW were I encountered the PAL (DX) issue with my card on my Toshiba SAT duo-core Centrino LT (w/integrated Intel GFX accelerator). That problem was eliminated when Remus made the changes I described to the new EW .exe he coded. I no longer have the prob and can run all versions of EW flawlessly. Right now I am only useing Remus's EW because I'm working on the new Campaign maps for 2200 which run our data set and binary.

- Cheers, RV

OK, thanks for the clarification.
But you got me curious again, is the png issue the same issue that everyone basically avoids talking about when I tried to find out what was wrong with Grim's png, or perhaps it was photoshop ?
I never did get a straight answer to this.  ???

[Rman Virgil]

OK, thanks for the clarification.
But you got me curious again, is the png issue the same issue that everyone basically avoids talking about when I tried to find out what was wrong with Grim's png, or perhaps it was photoshop ?
I never did get a straight answer to this.  ???

* 1.) When dealing with transparencies .pngs are a nightmare even for a thoroughly accomplished, professional artist. WHY make the GFX tasks MORE difficult than need be.

* 2.)  .Pngs donot support mipmaps in one texture. That's very important to the GFX quality evolution of WZ. Our ultimate texture format of choice will do this. What is that format ? You can figure that out I'm sure.

- RV

[Buginator]

* 1.) When dealing with transparencies .pngs are a nightmare even for a thoroughly accomplished, professional artist. WHY make the GFX tasks MORE difficult than need be.

PNG is just a format, you still use whatever paint program you want, and you still do everything you would normally do, except at the end, where you tell it to save in the PNG format.
It is no different than working with TGA.
That is the crux of the issue, I can't seem to find out *why*.
A package format should *not* matter to the designer, since they can save it in any format they prefer, and then export it out to whatever format is required for the project.  That is the way most professionals do it from what I understand.

* 2.)  .Pngs donot support mipmaps in one texture. That's very important to the GFX quality evolution of WZ. Our ultimate texture format of choice will do this. What is that format ? You can figure that out I'm sure.

- RV

Yep, but pcx don't support mipmaps either, nor does tga, jpg, and the list can go on & on.
I am pretty sure that format will be dds.
I rather like it, but I *think* the GPL people have issues with the license with that.

[Rman Virgil]

PNG is just a format, you still use whatever paint program you want, and you still do everything you would normally do, except at the end, where you tell it to save in the PNG format.
It is no different than working with TGA.
That is the crux of the issue, I can't seem to find out *why*.
A package format should *not* matter to the designer, since they can save it in any format they prefer, and then export it out to whatever format is required for the project.  That is the way most professionals do it from what I understand.
Yep, but pcx don't support mipmaps either, nor does tga, jpg, and the list can go on & on.
I am pretty sure that format will be dds.
I rather like it, but I *think* the GPL people have issues with the license with that.

* Should have been more precise.

* Make it look good enough in WZ running Alpha Png Support code.

* PNG transparency problems are infamous in quite a few progs... the fixes are a pain in the ass and (like in IE) you still have to go over issues related to padding, margins and absolute positioning... and so on.

* So yes .png is just a format and working in CS3 is NOT the problem. It's how the prog that uses the format is were the short-comings lay. Alpha png support code is not up to snuff, in other words.

* .PCX is the original source. We move ONLY from the original source. .pcx > ?.... NOT .pcx > .png > ?. Make sense ?

- Regards, RV

[EvilGuru]

There are not, and never were any problems with the PNG images produced by Photoshop. Anyone who says otherwise is speaking crap. Yes, they are slightly different to those produced by other applications (with regards to 100% transparent pixels), however they are *not* non-standard.

No ifs or buts here.

The reason the PNG images failed was/and is because of: a) How we load the PNG; b) How the renderer deals with certain colours. Should b) be the case then all image formats will be affected.

> * PNG transparency problems are infamous in quite a few progs... the fixes are a pain in the ass and (like in IE) you still have to go over issues related to padding, margins and absolute positioning... and so on.
IE 5 and 6 do have problems with 8-bit PNG images and transparency. The fix has nothing to do with padding, margins or absolute positioning. The usual fix is to use a DirectX filter (an IE-specific feature) to load/handle the .png image as opposed to IEs native loader.

> It's how the prog that uses the format is were the short-comings lay. Alpha png support code is not up to snuff, in other words.
Couldn't have put it better myself.

Mipmap support lacking in .png images... quite an interesting one actually. PNG is an extensible format which supports user-defined blocks inside of it. This allows one to extend the PNG image format. One of the best known examples of this was in Adobe/Macromedia Fireworks, whose native file format *is* PNG. Inside of the PNG image are layers, vector shapes, gradients, text... everything you would expect from an image file format. Better still, the image is still a PNG, so any application which can view PNGs can view the image (most likely a flattened version of it). It is possible for these user blocks to be used to store mipmapped versions of a texture.

GPL issues with .dds? In a word: irrelevant. Yes, some of the algorithms used are patented. However that is not a GPL thing. Furthermore, it would not be our problem. The patented algorithms are normally implemented in the graphics card driver, via an OpenGL Extension.

Regards, Freddie.

[Rman Virgil]

> * PNG transparency problems are infamous in quite a few progs... the fixes are a pain in the ass and (like in IE) you still have to go over issues related to padding, margins and absolute positioning... and so on.
IE 5 and 6 do have problems with 8-bit PNG images and transparency. The fix has nothing to do with padding, margins or absolute positioning. The usual fix is to use a DirectX filter (an IE-specific feature) to load/handle the .png image as opposed to IEs native loader.

* Again shouda been more specific - I was thinking when working with CSS.

Mipmap support lacking in .png images... quite an interesting one actually. PNG is an extensible format which supports user-defined blocks inside of it. This allows one to extend the PNG image format. One of the best known examples of this was in Adobe/Macromedia Fireworks, whose native file format *is* PNG. Inside of the PNG image are layers, vector shapes, gradients, text... everything you would expect from an image file format. Better still, the image is still a PNG, so any application which can view PNGs can view the image (most likely a flattened version of it). It is possible for these user blocks to be used to store mipmapped versions of a texture.

* Isn't it something like re-inventing the wheel when you could use something "straight outta the box" ?

GPL issues with .dds? In a word: irrelevant. Yes, some of the algorithms used are patented. However that is not a GPL thing. Furthermore, it would not be our problem. The patented algorithms are normally implemented in the graphics card driver, via an OpenGL Extension.

* Yup.

- Regards, Rman