• New Horizons on Maelstrom
    Maelstrom New Horizons


    Visit our website www.piratehorizons.com to quickly find download links for the newest versions of our New Horizons mods Beyond New Horizons and Maelstrom New Horizons!

POTC Vanilla Running in 2.8 COAS Engine

Well compared to the effort you made with porting PotC to 2.8 (I cant wait to have lights on my ships at night) the issue with the screenshots is so tiny ;)
 
ChezJfrey said:
Yeah, it was just odd that the code to create the TGA screenshot was fine in WinXP, but that same code, merely run on Win7, all of a sudden produced that issue with the alpha channel. I had to slightly adjust the code doing the bit shifting for TGA to also address that alpha channel issue. It now works, but again strange that it worked, but then suddenly didn't with the slight platform OS change. My goal was to not force a user to use other means to get a viewable shot, but rather just have it come out right away.
Click to expand...
I suppose having the screenshots written directly to PNG or JPG would not be a quick fix, would it?
Personally I've always been annoyed with it writing to TGA, because whoever uses that for their screenshots? :facepalm
 
Pieter Boelen said:
I suppose having the screenshots written directly to PNG or JPG would not be a quick fix, would it?
Personally I've always been annoyed with it writing to TGA, because whoever uses that for their screenshots? :facepalm
Click to expand...

LOL, now I feel stupid...of course!

In a test of 3, the .jpg is 732 KB, .png is 2,754 KB and the .tga is 6,076 KB. The .png was horribly latent...took about 1/3 a second with a noticeable freeze in the game screen, whereas both the .jpg and the .tga were near instantaneous. Three are zipped at below link...which is preferred?

MEGA
 
The following is NOT based on the contents of that ZIP because I'm on my phone and attachments generally don't work well on that.

I think PNG gives perfect quality, but it often results in files too large to upload to the forum.
So virtually always, I end up converting all pictures to JPG before using them anywhere.

Only reason I'd want perfect quality is if the shots are to be used for, for example, Loading Screens.
But for that, I normally use Print Screen and Paint which works fine for that.
That's my preferred method for making shots in PotC anyway.

Since the ingame screenshot button would be most important for regular players, rather than developers, if a choice is to be made, I'm inclined to suggest JPG.
But both have their advantages and either would be better than TGA. :onya

ChezJfrey said:
LOL, now I feel stupid...of course!
Click to expand...
No need! You are doing far more clever stuff here than I ever could. ;)

Plus, if I read your post correctly, you ALREADY MADE IT WORK and that's really very awesome!
I was afraid that it would be very, very difficult and I almost felt bad for even suggesting it.
So I do believe congratulations are in order. :cheers
 
In the early pre-Internet days of USENET there was a major argument going on about whether to use GIF or JPG for images.

The problem was, those early JPG images were hideous quality, full of artifacts, and mostly unusable. GIF wasn't without some problems, besides huge file sizes, and I've still got a few GIF images from the early 90s that show objectionable color banding. I couldn't buy an image editor for GIF files in those days because Compuserve owned the rights.

Then, one day, someone posted two identical images, one in GIF, the other JPG. The JPG was *much* smaller and had no apparent artifacts. And it's only gotten better since then. Today you can resave a file multiple times and still maintain the quality, unlike the earlier days.

Now days, the only GIF images you see are animations. :)

Some of those uncompressed formats are much easier to manipulate in a computer program, which is why they're still around.

Hook
 
Pieter Boelen said:
Plus, if I read your post correctly, you ALREADY MADE IT WORK and that's really very awesome!
I was afraid that it would be very, very difficult and I almost felt bad for even suggesting it.
Click to expand...

Thanks. It certainly could have been difficult, as I really have no knowledge of the different image specifications. But, one thing greatly eased the change in DirectX 9, which is what I used for the examples, and another separate piece of code eased the TGA fix for DirectX 8.

DX9 already has a built in function to directly take an image surface and convert it to a physical disk file. Worked great for .jpg and .png. Feed it an in-memory surface object, a file name, what type of image type you want, and voila! However, though it does provide for a file-type of TGA, the documentation indicates there is technically no support for TGA and it didn't work. But, an experimentation of using the existing portion of code that does one bit shifting, AND using that same DX9 function afterward, proved successful to create a valid TGA; oddly, that same bit shifting, with output direct to a file without the function call, as it was done before in the 'old' way, no longer worked, but used to prior to my using Win7 to run the game.

Now, that worked for DX9, but my DX8 library did not contain that same useful function. But, I some searching led me to a piece of open-source code that claimed to convert a DX8 surface to a file that was different than what I found in the original source of this game. I found that in certain cases of the original display format, it shifted some extra bits of each byte. It also adjusted the bit value in certain cases. Again, I don't know TGA specs at all, no idea if this was 'accurate' for that format, but gave it a try. It worked in DX8.

Which leads us to now, which is my example was DX9 doing all 3 types, I can get TGA in DX8, but it does NOT contain the easy function to give me .jpg or .png and I don't know those specs at all to do it myself so I can't really do the same for DX8 just yet. But, I just found that my DX8 .lib does not have that function, but a very slightly older version on my computer DOES have that same function. I am now going to experiment and see if I can compile in that .lib and use it the same way DX9 worked. My game will still use the newer .dll, as all a .lib does is contain the function addresses and acceptable parameter types within the .dll. My guess is that the function still exists in the .dll, but the compiler can't obtain the proper address or function types and won't allow a compile of source using that function. I am going to give it a try and find out.
 
Ha! Worked! Kinda... Compiled like I thought it would with the slightly older .lib file. But, it turns out DirectX 8 only supports .bmp with that function. I tried .jpg and .png that worked with DX9, but got no file at all. Did some searching and found some conversation that back when that function was being used, it only supported .bmp and .dds. So I tried a .bmp and got a .bmp file! Of course it's as large as a .tga of 6,000+ KB :)

So...kinda.
 
I think going forward, I'll roll with the .jpg for DirectX 9 as it's a common format, the file size is small.

For DirectX 8, I'll go with .bmp as it's also common and the file size is the same as .tga. But, for the average person, they will readily have a program that by default, opens .bmp, whereas .tga often requires a special program they might not have. Though IrfanView and some others are freely available, this will preclude having to install another special program just to view their screenshots for this game.
 
ChezJfrey said:
I think going forward, I'll roll with the .jpg for DirectX 9 as it's a common format, the file size is small.

For DirectX 8, I'll go with .bmp as it's also common and the file size is the same as .tga.
Click to expand...
I wonder why anyone would still need DirectX 8 if you can use 9. Even Windows XP supports up to DirectX 9, if I understand correctly.
Would it be possible to just use JPG with DirectX 9 and do away with DirectX 8 altogether?
 
Pieter Boelen said:
I wonder why anyone would still need DirectX 8 if you can use 9. Even Windows XP supports up to DirectX 9, if I understand correctly.
Would it be possible to just use JPG with DirectX 9 and do away with DirectX 8 altogether?
Click to expand...

A couple reasons I have kept it. First, it was already built, so why not keep it? But secondly, and most important, when I changed over to DirectX 9, there were a handful of the shader .sha files (literally 5 or 6 of them) that failed to assemble correctly and would not work. I searched all I could for some sort of instruction about how to fix the asm within them, but could not find what I needed, as most shading appeared to have moved toward HLSL, rather than the older asm model. I admittedly know next to nothing about either of these things and DirectX programming in general. The asm model requires that certain data elements get declared and used within certain registers for certain effects, but I don't really know what the implications of the different registers are for on the back-end of the DirectX shading. Some were self explanatory and I was confident, but others were ambiguous enough that I couldn't be sure what they were for without knowing how these things work in DirectX. Here are the usages:

D3DDECLUSAGE_POSITION
D3DDECLUSAGE_BLENDWEIGHT
D3DDECLUSAGE_BLENDINDICES
D3DDECLUSAGE_NORMAL
D3DDECLUSAGE_PSIZE
D3DDECLUSAGE_TEXCOORD
D3DDECLUSAGE_TANGENT
D3DDECLUSAGE_BINORMAL
D3DDECLUSAGE_TESSFACTOR
D3DDECLUSAGE_POSITIONT
D3DDECLUSAGE_COLOR
D3DDECLUSAGE_FOG
D3DDECLUSAGE_DEPTH
D3DDECLUSAGE_SAMPLE

I looked through the .sha files that failed and found some comments next to some of the variables (e.g. sometimes a short word for what they were for), the asm code variables, the assemble error, the DirectX 8 deprecated 'stream' model of informing about those variables, and after much reading, took my best guess about how to fix the .sha and declare them properly. Given that is what they were, my best educated guess, they could be wrong. They assemble without error now, but I can't say for certain they are now rendering properly, as intended.

So far in my use of the game, which has been a fair amount, it looks right and I haven't noticed anything odd, other than in some sand shores, it might have a slight bit of a greenish tint (e.g. notably Broken Washbasin) . Other than that, looks good...especially the sea, sky, buildings and ships. Now the problem is that if there appears something completely unacceptable in the shading rendering of DirectX 9, I have no idea how to fix it since I don't have experience or knowledge of how to adjust the shading declarations and associated asm code in the .sha files to achieve effects and/or adjust them. So that is why I kept and still offer the DirectX 8, which both of them have received the same fixes/updates for errors/crashes I encounter and these additional features I mention; if my DirectX 9 shading is inappropriate or 'bad', I want the original that still caters to the original .sha files since that is what it was written to (DX8) as a viable alternative.

Unless you know someone that can interpret the DirectX 9 declarations and shading asm to tell me if it appears correct? I don't know anyone that does DirectX programming, so that is where things still stand in the development.

Unrelated, I changed my mind about how to deal with the screenshot file types. I am going to allow for start.ini options. DX8 will support .bmp and the old .tga, while DX9 will support .bmp, .jpg, .tga. If not specified in the .ini, it will default to what I mentioned (.bmp for DX8 and .jpg for DX9). That way, if people still want the .tga they are used to, it will do so.
 
Good work, @ChezJfrey. I see no need to support TGA when BMP will do the same thing, and if all you want is a screen shot picture, then JPG is the way to go.

There will be times when someone wants to extract game graphics from a screen shot, and for those BMP will be better because there's no compression: what you get is an exact duplicate of what's on the screen. JPG might give you some unwanted compression artifacts.

I'm not currently familiar with the TGA file format, but that bit shifting problem sounds familiar. We had it with another game that probably saved in TGA format, and I had to write a program to unshift the bits on the final file to fix it.

Hook
 
Where is Broken Washbasin? I saw it in COAS but can't find it on the PotC map. It's on Bermuda in COAS, and PotC doesn't have that island.
 
ChezJfrey said:
Unless you know someone that can interpret the DirectX 9 declarations and shading asm to tell me if it appears correct? I don't know anyone that does DirectX programming, so that is where things still stand in the development.
Click to expand...
My knowledge of DirectX is quite literally limited to "knowing it exists and that higher numbers are probably better".
Other than that, I haven't a clue what it does, how it works or why. So I'm afraid I can't be of any help there. :(
 
LarryHookins said:
Where is Broken Washbasin? I saw it in COAS but can't find it on the PotC map. It's on Bermuda in COAS, and PotC doesn't have that island.
Click to expand...

Ha, I was referring to COAS in my DirectX 9, as I never had prior experience with how POTC looked, but could compare COAS DX8 and DX9 and could see a slight difference at that spot at the Bermudes island. It's not terrible in the sense that things are blasted, but it has a slightly different tint to it...at least seems to appear so to me.
 
Ok. I did a teleport there (had to look up the right code to use), and it looked OK in the stock game. No greenish tint. I did see the base of the island with no fog shading, looked odd, but had seen that on a previous trip.

And now I know how to teleport. :)

Hook
 
Looks so great!

I might be a little late, but I'm curious, how did you do it? Which files did you copied? If it's not a top secret :)
 
Well, it seems I'm gonna have to find it out myself.
But no problems, at least I will learn, and will be better in such stuff :D
 
May I assume that an engine update is on the way for the old New Horizon (if we consider the unity development as an other project)? We've been hoping that for years!
 
You must log in or register to reply here.
Back
Top