EAW in need of a Hardware Programmer

[MarkEAW 63]

Volunteer Programmer Needed:
The EAW community is in need of Volunteers to code updates for this Windows 95 designed game. It currently runs under legacy compatibility layers or fixes provided by WinXP , WinVista (and the newer modern Window OS's). In some situations an external Wrapper Program or Registry Fix is needed to run the game with out problems, or with reduced issues.

These are major things that need to be improved to keep current EAW enthuses and to attract newbie's to stay.

-DirectX version needs to go from DX5/6 to at least 9.0c/9_1 so modern drivers and hardware can be taken advantage of by the game and the video control panel settings will work. There is No Horizon Fog in D3D when using Nvidia Cards and there are lower Frames per second in DD/D3D performance in flight.
-Add modern Hardware compatibility, primarily proper GPU usage.
-Update the in-game 8-bit front-end of EAW to 32-bit. Right now it uses the old DirectDraw to display. Its faulty; the menu, map and briefing screens do not have perfect color, and at times are garbled (tearing), sometimes corrupt.
-Memory management intended for Win95 seems CPU intensive rather than GPU.

The fixed up compliable v1.2 source code is in a mixture of "C", "C++" and assembler. You can use Microsoft Visual Studio 6.0 (In WinXP) to work on and compile the code. A custom DX6 SDK (although the DX7 SDK should also work) can be used.

There is no programmers available to update the code to issue hardware repairs to the game at this time. Not many of the current EAW source code users have looked for new programmers. A few old timer EAW enthuses have tried to find someone in the past , but no luck in the end. So I thought I'd re-mention it here. I'd personally, would like to see this before some of us pass on, either by them leaving the EAW community or by the older EAW users dyeing off.

I wasn't put up to this, I just decided to see if there is really anyone willing and capable of doing these updates. Please contact if seriously interested at CombatACE or SimHQ forums.

Edited May 20, 2019 by MarkEAW
improved text, more informing again.....

[VonBeerhofen 63]

Mark, I'm afraid the code isn't open source which is why it can not be shared. That only leaves programmers to share their knowledge with the people who have copies and have been working on improvements. Since EAWPRO and v1.60 are already actively competing there's no real chance that any hardware programmer would share his time to teach others how to change/upgrade it the way you would want.

You can't work on the code if you don't have a full copy of it, especially not when it comes to understanding which hardware features have been used. I would really like to see these improvements in EAW but my personal view is that I do not want it to be turned into something entirely different. EAW has stolen my heart right from the start and I would even still have played it without v1.60 or EAWPRO.

If the result would be that only small theatres can be played, like I've seen in many other much more graphically enhanced games, then for me it's no longer EAW. Don't forget that this game can have up to 256 planes fighting eachother with you or me in one of em and that in a massive theatre of entire Europe ,or whatever other continent has been created for it. I'd rather see even more planes in an even larger theatre then seeing a graphical enhancement take place which will probably only limit such furballs.

I agree that it's cumbersome sometimes to get the game to work and with decent FPS too, but it can be done. To turn this game into an equal of a modern flightsim will take years, even with a group of dedicated people. It's too massive and there's so incredibly much to be done to create even the smallest improvements. FAW for v1.2 took Per roughly 5 years to build and he nearly gave up before he finished it. Imagine having to create all new file formats to take advantage of modern hardware and then adapt everything that has been created up till now. What has been accomplished has taken the codegroup and me 13 years.

I think only a commercially interested owner may have the resources to do it, with professionals who know what they're doing, not a bunch of hobbyists like us. No matter how much we would like to help, it would mean the end of a hobby as I don't think anything we create would be able to compete. It's not that it would stop me from doing what I do, I'm too old to do anything else and I will still play EAW when they put me into a home for the elderly and work further on it, after all every person should have a hobby and this is mine.

VonBeerhofen

[MarkEAW 63]

eh, no new formats, the game would end up being either coded to translate on the fly, or the old data would be read natively but in an updated DX code and new proper 32 bit menu system.

The source code and SDK is out there for 1.2. But I'm looking for someone for Jel to coordinate with, regardless. If not then someone else.

The only thing holding back new comers to just use EAW (not to play even, but use) is the damn Menu Screens being color screwed up and the tearing. Plus the faults of Direct3D/DD in the flight screen.
I've seen a single programmer take on much larger tasks then this, so I'm not concerned at all for a real programmer to complete these small updates.

Its not building a new game.. It can then be taken advantage of and added to Jel and Co 160, all his additions would remain, its just be an hardware comp update, no reg fixes or wrappers. Its already a Windows Game.

It can be done easily to someone that has a few weeks to months. I know you don't support this but you'll see if it comes true.

The only thing is I don't know how the FXEXE eaw.exe can be ported to the new code, since everything is machine level and hex inserted.
I don't understand how so many patches could be easily readded if thats even the method.

To the future. :\

[VonBeerhofen 63]

I do support it and I wish I could figure out how to make it work. I've been led to believe that the solution was in the larger sized .BMP screens, it just needs to be something that all modern videocards and monitors can work with. If .BMP isn't doing it then I don't know what will.

All I can do is keep experimenting and hope for the best. It may not be feasable to change it for EAWPRO at the moment but if it can be fixed for 1.60 then I'm happy for Jelly & Co and the EAW community. Sadly I still can't do much here, perhaps when winter comes. I've not had any  such issues, it needs a computer with the screen problem and I don't have that problem, neither do the Launchpad pilots. It's just why I'm spending very little time on it.

VonBeerhofen

[MarkEAW 63]

Modern video cards will be able to display the current formats. I could dive into research mode and try to provide facts, but I seen dos games turned into windows games with the same game data.

I wouldn't bother with the menu display problems...it just needs proper support coded for them that's all. No need to spend time where it will only work for some and not others.
Wrappers do the job for now.

I've heard things too like the models will have to be done over, not true. The 3DZ models will still work.
I can't prove it, but I can base it on how other games where supported with new coding with the same data used.

Let there be light ;)

[+gerwin 451]

22 hours ago, VonBeerhofen said:

If the result would be that only small theatres can be played, like I've seen in many other much more graphically enhanced games, then for me it's no longer EAW. Don't forget that this game can have up to 256 planes fighting eachother with you or me in one of em and that in a massive theatre of entire Europe ,or whatever other continent has been created for it. I'd rather see even more planes in an even larger theatre then seeing a graphical enhancement take place which will probably only limit such furballs.

Was lurking this topic already, good luck with EAW in any case. (I hardly played it myself.)

I like your attitude quoted above. I keep my Strike Fighters install pretty lightweight for similar reasons. Gameplay above graphics any day, and I can't stand loading times either, especially when testing mods.

 

1 hour ago, MarkEAW said:

Modern video cards will be able to display the current formats. I could dive into research mode and try to provide facts, but I seen dos games turned into windows games with the same game data.

Videocards don't display any specific image formats as identified with their file extension, with the exception of support for NVidia .DDS compression variants DXT1 to DXT5. Video cards display bitmaps in the general sense, like a map of bits. Bitmaps are extracted from their disk-format at the time of reading them from the disk. Like one can read a 8-bit indexed color compressed .png image from disk, and right after reading it and decompressing it, use the attached palette to translate it to true color: You then have true color bitmap data to do whatever, just have to remember width and height and can forget the rest of the original file header.

When I do a internet search, I read that EAW uses Direct3D with  8-bit paletted textures internally. I figure 8-bit paletted textures made some sense then, to use less memory, like just 1/3 compared to true color textures. In all other ways it just sucks. Hardware support for it was brief and long gone, but the Direct3D API + Video Drivers probably have emulated support for it. AFAIK the way to go for an improved EAW is to ditch all palettes as soon as the textures have been loaded from disk, and use true color internally. Easier said then done though.

Edit: As for the topic name, you don't need a hardware programmer really, but a Direct3D API programmer.  It is like this: Game -> Direct3D API -> Windows Video Driver -> Video Hardware. (I never programmed Direct3D API myself, I am not a real programmer anyways)

 

Edited July 17, 2018 by gerwin

[+gerwin 451]

About the amount of work; It depends a lot on the state of the code.

Just as an example; Compare it to an old game with a small fixed resolution like 640x480. In some cases these games were actually programmed with abstract and flexible resolution handling, and just changing a few values makes everything scale properly, to 1024x768 or something. Because the original code already had the procedures to scale things. Other games make assumptions about being in 640x480 mode all over the place, and it is a lot of work to find all these places and replace them with scaleable code. Especially when assembler code is involved with it. In the worst case you'd have to conclude that the old rendering code was a bad job and needs a complete rewrite.

EAW 3D rendering code should be reasonably modular at least, since it supports both Software + Direct3D + 3DFX-Glide. Meaning that the code was made to handle three different rendering paths. In the EAW 1.60 version I just tried (It runs!), there is obviously a dithering effect in the video output. Probably used at the time to improve the looks of the game by reducing color banding, but dithering is not beneficial for true color games, so it would have to be removed. 

I am sorry if my remarks sound annoying, I sensed a little confusion over this subject and this is my try to help out.

Edited July 17, 2018 by gerwin

[MarkEAW 63]

yes, it uses directx 6 (d3d and DD) or glide 2.43 for the flight screen.

The menu screens are 8 bit color (256) and us directdraw to display. (They corrupt with color issues and tearing (garbled) on some of them.)
This is the primary problem for just running the single eaw.exe exe (it uses a d3d.dll btw too, but I don't really know what for)

Edited July 17, 2018 by MarkEAW

[VonBeerhofen 63]

I've done some more tests with PicPac, the converter for PCX files (amongst others) but nothing came out usefull. Tried 8 and 16 bit screens, think I've done that before on another videocard, and tried the various available switches to see what would happen.

Anything other then the default -8 or -p switch resulted in a black screen but the game ran and when I blindly hit a menu item the game progressed. Exiting out again the main screen became visible but with weird desertlike palette colors, shown in a screenshot I took (you can view the palette in that shot as it's in 8 bit).

There's a -raw option and two bitmapped switches in the GUI that someone wrote, the -raw produced an empty .PIC and the bitmpped switches produced the still operational black screen. I didn't have my notes as they were still on my broken WinME machine but according to the GUI PicPac can handle various picture formats, including  .GIF and it makes me wonder if those can be packed and work the same as a .PCX. An 8 bit .GIF is app. 30 - 40% smaller then an 8 bit PCX and would safe a lot of space on my computer. Sadly I can't start converting 1000ds of files but if that works I might start using it instead.

Furthermore output can be clipped to a fixed size but I have no idea how to set it in a .BAT, I tried a few things but got no result. The good news however is that I got my WinME drive out and hooked up to my docking station and successfully transferred the code, my assembly translations, my notes and lots of other goodies, so I'm back in business, horray!

The search continues,

VonBeerhofen

[Jel 37]

I have just returned from a holiday in Switzerland.

Just to give you an idea of the complexities this is an edited overview from the 1.2X code, relating to some of the picture and menu reading code, broken into three sections.

Many of the routines referenced are called multiple times in dozens of "c" files

 

SECTION 1:

Picture loading/reading routines called in "readpic.c":

void readpaltopal

void readpictopal

void readpictopal16

size_t readpicheader

size_t ReadPicHeader

void LoadMenuColors

void UnloadMenuColors

*********************************************************

SECTION 2

"Readpic.h" header file:

/*
** READPIC.C stuff
*/

//
// Stuff for pic files.
//

#define PIC_VERSION 0x0500

#define PIC_PAL_DEFINED   0x0001
#define PIC_BIT_MAPPED    0x0002
#define PIC_NO_IMAGE      0x0004
#define PIC_SEGA          0x0008        // just here for compatibility ** Not Used **
#define PIC_8_BIT_PAL     0x0040

//
// Compression window sizes.
//

#define PIC_WIN_2K        0x0000
#define PIC_WIN_4K        0x0010
#define PIC_WIN_8K        0x0020
#define PIC_WIN_16K       0x0030
#define PIC_WIN_SIZE_MASK 0x0030

//
// Header for .PIC files.
//

typedef struct
{
    UWORD  Version;            // Version of compressor
    UWORD  Status;                // Status flags. See above
                                    // Note: If the PIC_PAL_DEFINED bit is set then
                                    //       the palette is defined after this structure as
                                    //       256 RGB values. (768 bytes)
    short  Width;                // Width of image
    short  Height;                // Height of image
} PicHeader;

typedef struct _DiskColor    // this is how the palette is stored on disk
{                                    // as a tripplet RGB
    UBYTE Red;
    UBYTE Green;
    UBYTE Blue;
} DiskColor;

void readpicnopal( Window *window, char *filename);
void readpaltopal( char *filename, PALETTEENTRY *palette);
void readpictopal( Window *window, char *filename, PALETTEENTRY *palette);
size_t readpicheader(char *filename, PicHeader *hdr, PALETTEENTRY *palette);
size_t ReadPicHeader(int file_handle, PicHeader *hdr, PALETTEENTRY *palette);

/*
** LZW.C stuff (The un-compressor)
*/

void LZWBufferUnCompress(void *LZWBuffer, void *WinBuffer, PALETTEENTRY *palette);
void LZWUnCompress(int file_handle, Window *window, PALETTEENTRY *palette);

//
// LZW Defines
//

#define MMAXBUF        16384
#define BUFBITS        14
#define MAXRUN         255
#define LZW_XEB_SIZE   (MMAXBUF+MAXRUN)

#define DISK_BUF_SIZE  2048

//
// LZW token def.
//

typedef struct
{
    UWORD   pos;
    UWORD   run;                           
    
    short   trailerLength;
    UWORD   trailerPos;     

} lzToken;

//
// Expansion buffer (can be used for other things)
//

extern UBYTE LZW_XEB[];
extern UBYTE DiskBuf[];
***********************************************************************************************

SECTION 3:

Select cases in menu reading, many of which call picture reading routines:

                case LM_MENU_ALLOC:

                case LM_ALLOCFSMENU:

                case LM_SCREW:

                case LM_BULLET:

                case LM_HSLIDER:

                case LM_HOT_SPOT:
            
                case LM_VSLIDER:

                case LM_LOADPIC:

                case LM_LOADPICPAL:

                case LM_INIT_CODE:

                case LM_PIC_NAME:

                  case LM_HEADER:

                case LM_MENU_ANIM:

                case LM_TEXT:

                case 27:    // LM_DUPE_TEXT:

                case LM_RAISED_AREA:

                case LM_RECESSED_AREA:

                case LM_BOX:

                case LM_RECT:

                case LM_FILLED_RECT:

                  case LM_LINE:

                case LM_CENTER_MENU:

                case LM_BUTTON:

                case LM_CLEAR_COLOR:

                case LM_END:

Jel

 

 

[MarkEAW 63]

Looks simple MrJelly :) But IDK...the 8bit code would probably get dumped, and be easier to code a new 32 bit front end reading the same game data. But who knows what would happen....!?

What is the d3d.dll file for? or didn't anyone figure that out?
(I know it was modified atleast at one point).

Edited July 20, 2018 by MarkEAW

[VonBeerhofen 63]

What's important to understand Mark, is that the Source Code will remain in the hands of those who have no clue on how to tackle these issues other then the way it's currently being done.

As for the .DLL, updating it is useless when no additional routines are programmed to call on the extra entries. Simmilarly previous efforts had no effect whatsoever but the file got bigger and being bigger means that it takes more time to link the entries with the hardware in use. I've tried all available versions for longer periods of time and didn't notice any difference. You can implement vertex graphics to the .DLL but you'll have to write a routine to make use of it. The smallest .DLL was incorporated in the code, it's smaller then the released version if I remember correctly, but it worked just as good on my machines and I haven't received any negative feedback from players about the other versions I may have incorporated at times to see if others would have a problem with them.

A change to the .DLL is ineffective untill certain things in the game routines are changed, this means that even when the problem is one or more entries in the .DLL, changing the .DLL alone will not solve the problem. The fact that some people tried nonetheless is only indicative of the amount of knowledge people had on the subject in those days.

VonBeerhofen

Edited July 21, 2018 by VonBeerhofen

[+gerwin 451]

On 20-7-2018 at 5:46 AM, MarkEAW said:

Looks simple MrJelly :) But IDK...the 8bit code would probably get dumped, and be easier to code a new 32 bit front end reading the same game data. But who knows what would happen....!?

What is the d3d.dll file for? or didn't anyone figure that out?
(I know it was modified atleast at one point).

Attached below is a function list of D3D.dll. It does not seem to be a wrapper, since the function names give me no matches with Google search. So I figure it is just (part of) the Direct3D rendering code. For 3DFX-Glide I would expect a similar DLL called glide3x.dll. This glide3x.dll is mentioned in the EAW exe, but maybe it is statically linked, thus included in the exe?
d3d.dll.txt

I tried EAW barebones v1.60 on another computer: WinXP, Radeon HD6670. Now the textures seem smoother and I cannot see the dithering like on the Intel HD system. But the mouse cursor remains visible in the center at all times, but I can get rid of it with "Windows 2000" compatibility mode. Some windows file icons change after running this game, this may be indicative of a problem in exitting the game?

In d3d.dll there is the function "d3dSupports8BitTextures". Well ATI/AMD radeon never supported that in hardware, so when it gets a NO answer; there the game might actually behave better. 

Edited July 21, 2018 by gerwin

[MarkEAW 63]

the d3d.dll was changed a few times, hacked once I think for v1.26 and then coded for v1.28c. Maybe something to do with the menu screens, but I'm not sure. Been awhile since I read the changes they made.
PS, Thanks VBH for the info.

Since the glide2x.dll was part of the Voodoo vid card drivers, you don't see those DLLs in the eaw directory. But you may if using some wrappers with eaw in glide mode.

The Intel videos is limited as far as I know. I'm surprised it worked with yours without a wrapper, but maybe its win10 compatibility layers at work.
You should see horizon fog with your Radeon Vid card too. I don't think it will show with the Intel chip in Direct3D.

BTW, you don't want to use win2000 compatibility tab setting in Winxp. Winxp sp1 or sp2 and up has all the necceary compat layers/fixes. With the Tab setting you may loose joystick control.

Edited July 21, 2018 by MarkEAW
vbh info thanked.

[Jel 37]

The mouse cursor is an easy fix.

Create a shortcut to the eaw.exe on your desktop, or in the taskbar and use it to launch EAW.

With the more complete 160 installations there is a "launch" burtton on the filemanagers.

[MarkEAW 63]

gerwin, thanks for your responses about the terms and the way stuff works.

The one thing I don't know for sure it what type of graphical enhancements the game provides on its own, rather than Post processing.

By the looks of it , Biliner filter is used. But I don't know if this is automatic or it must be set with a Wrapper Program or by the video control panel first for the game to activate that type of filtering pre post?
Also MipMap seems to take the shimmer out of the distant terrain in glide mode.

There are no options to turn on or off graphical enhancements. I assume they automatically turn on if the hardware/drivers support, yet IDK for sure.

I would like to know a list of enhancements the game is capable of though, anyone know?

Edited July 29, 2018 by MarkEAW

[VonBeerhofen 63]

Mark,

EAW will use Bilinear and Anisotropic filering, mipmapping and a few other things I've never heard of for both Glide and D3D, depending on finding the capabillities for it in the hardware. These features are again linked with poly types and texture types, which the hardware  must also be capable of doing if the above features are to be used.

Effectively both the polygons and textures are under control of modders, so these features can be turned off by using polygontypes or textures which will not trigger these features. Obviously in software mode none of it will work and it's also not in anyone's interest to force the game to do a lower level graphics mode then what the hardware is capable of.

I've played with some of these features to try and force it to turn on, if my card couldn't do it. Bilinear filtering only switched off thin lines in the 3D models as well as all single line polys in the structures when you'd get close to the object, the information simply vanished. So I guess my card can't do it.

I think my gForce FX5500 could do it but I can't say if it would do the same thing by forcing the polygon type which was said not to use these features. I removed the forced entry a few days ago as it seemed useless in that the game will use different types of polygons if the hardware can do it. The switch to these polygon types is automatic so if my card can do it forcing it for polygons which aren't meant to do it is useless.

I couldn't find any evidence of post processing features, but I recall my FX5500 could be switched to force mipmapping, and I guess that goes for all other features that card could do. I've played around with most settings but in the end just opted for good quality and speed. 

Whatever features the game has build in is not going to evolve with my knowledge, I rely on the features modern videocards are capable of, if it can do post trilinear filtering, great, when it can't, too bad. I recall I could set tripple buffering which doubled my poor FPS, having an 8 times AGP card in a 4 times AGP slot. Without it I wouldn't have been able to play the game, so that was great but the effect of the switch was unknown on forehand. People just will have to experiment with ingame settings and videocard settings to find the best results.

For me that's where my interest faded, experiments didn't have any advantageous effect and it was already dangerous to do those experiments in the first place, I may even have destroyed my videocard with it. So I definately am not going to tamper any further with stuff I have no idea on how it's programmed, I stick to what I know/understand and have done for 35 years. Searching for this stuff is a waste of time, I just wait untill I find something I understand and then start work on it, it's much more productive and perhaps at a later stage things will become clearer so I can try with less of a gamble. A little bit of risk is always involved but I intend to keep it to a minimum. If this or my other computer fails I'm out of business for good.

VonBeerhofen

[MarkEAW 63]

Thats what I thought, since there's no settings for graphical enhancements, perhaps EAW would automatically detect what it supports and uses it. (that is if the hardware/video driver support it).

[MarkEAW 63]

I guess no one is interested at this point in updating the games DX code and etc.
We'll have to wait I guess, or not.