COMPILE: Linux Port

[lynx_abraxas]

Forgot: As Sciencemanager works fine now I played around in it a bit and noticed that the pic for the advance slavery has the same artefacts as the mouse pointers. Other pic of advances are fine though. It came to my mind that the green looks pretty much like the one seen when things are in overlay mode of the graphics card. Then a colour (normally green) is used to display the overlay through it. Well just a thought as I'm not really knowleged of overlay.

Does anyone know how I can increase the scren res now?

[lynx_abraxas]

What about taking the address of int casting this to void* and then doing the dereferincing as it was? Would be better, woudn't it?
Should I commit these chages to svn?

[J Bytheway]

Originally posted by lynx_abraxas
What about taking the address of int casting this to void* and then doing the dereferincing as it was? Would be better, woudn't it?

Only if you can be very sure that the int is not a temporary.

You're right that sizeof(int) might not be sizeof(void*), but I think the latter will always be bigger, so it should work. IIRC, the bug you encountered was introduced by someone misunderstanding what the code was doing (they thought it was doing what you're suggesting it be changed to).

Anyway, be careful, whatever you do .

[lynx_abraxas]

Good point about the temporary state. But thinking about this further: Wouldn't the void* beeing the casted int not live as long as the int would?
Could it be one would have to make a copy of the int with new giving this new location to the following functions and destroy it there just befor returning?

Changing
reinterpret_cast<void*>(advance->GetIndex())
to
reinterpret_cast<void*>(&(advance->GetIndex()))
leads to this gcc message:
ui/interface/ScienceManagementDialog.cpp:383: error: invalid lvalue in unary '&'
What's wrong here?

[lynx_abraxas]

Playing on till I met the first Barbarian and Battlescreen opening I get the next Segfault. It looks like in FacedSprite.cpp in FacedSprite:rawDirect the pointers in m_frames[k_MAX_FACINGS - facing][j] for any j are still NULL (used in this->*_DrawLowReversed).
Any idea where these should be pointed to some addresses of Pixel16-values? Well, without Battlescreen it does not segfault.

There is an Assert-abort when reloading another game:
../../../ctp2_code/robot/aibackdoor/pool.h:338: void Pool<DATA_TYPE>::Release_Pointer(int) [with DATA_TYPE = SlicSegment]: Assertion `next_free_element_list->Return_Data_By_Number(ptr_to_free) == -1' failed.
I didn't go into this one so far. I would prefer solving the tile blending in max zoom first. Can anybody point me to places where the bug might come from?

[lynx_abraxas]

Solved tile blending in max zoom. It's not perfect though. Is anybody able to translate the M$C asm-inline code to gcc __asm__ code, which is AT&T style? It's in ctp2_code/gfx/tilesys/tiledraw.cpp around line 4129. I took the code from TiledMap:rawBlendedTile which is C++.
Also got fullscreen working with a list of supported hw modes.
Is it already possible to add options with parameters, like -g 1024x768?

Next I'd like to get the cursor fixed. Any ideas where to start?
Also having animated goods would be nice.

[J Bytheway]

Originally posted by lynx_abraxas
Good point about the temporary state. But thinking about this further: Wouldn't the void* beeing the casted int not live as long as the int would?

There are too many negatives in your sentence - I can't figure out what you're asking.

Could it be one would have to make a copy of the int with new giving this new location to the following functions and destroy it there just befor returning?

You *could*, but it would be a recipie for disaster - you'd be almost certain to end up with memory leaking left right and centre, or worse things.

Changing
reinterpret_cast<void*>(advance->GetIndex())
to
reinterpret_cast<void*>(&(advance->GetIndex()))
leads to this gcc message:
ui/interface/ScienceManagementDialog.cpp:383: error: invalid lvalue in unary '&'
What's wrong here?

Probably you're trying to take the address of a temporary, as I was mentioning that you shouldn't.

[lynx_abraxas]

Originally posted by J Bytheway

There are too many negatives in your sentence - I can't figure out what you're asking.

I ment: Would the void* beeing the casted int live exactly as long as the int would?
But I think that's not the case, as the void* is a variable and the int has no place and is just a value. It works the way I have corrected the cast, so I'll leave it as it is.

You *could*, but it would be a recipie for disaster - you'd be almost certain to end up with memory leaking left right and centre, or worse things.

Probably you're trying to take the address of a temporary, as I was mentioning that you shouldn't.

It's because the return value of a function may not be in RAM but also in a register. So referencing a value is not sensible.

[lynx_abraxas]

I tried two nights now finding this artefact bug in the cursor and the improvements building queue. I first suspected a wrong chroma key but now having investigated this further I think it is a bug comming from AUI_SURFACE_PIXELFORMAT_565 being mistyped somewhere as AUI_SURFACE_PIXELFORMAT_555. Also g_c3ui->Primary()->PixelFormat() in civ3_main.cpp is giving me greef. It returns the wrong AUI_SURFACE_PIXELFORMAT which should just depend on g_is565Format.

The screenshot You posted in http://apolyton.net/forums/showthrea...63#post4046963
shows no sprite. Which should be fixed but isn't continueously. Sometimes they vanish when having finishe their animation. Exception is the Phalanx it stays visible and seems to have a chroma key set somewhere extra. (very strange)
At the time You took the screenshot, did the game continue?

Observing the svn revisions, only changes are done at /trunc at the moment. Are those modifications for bringing the /trunc to sync with /branch/linux or are there also modifications added to /trunc that aren't in /branch/linux?

[lynx_abraxas]

Forgot: How did You take the screenshot? Is there a function like in CTP1 with the print-key?

[lynx_abraxas]

Can someone point me to the file in which the actual drawing takes place? Where the pics and the mouse-pointer are put onto the SDL-main-surface?
This is a screenshot showing the artefacts on the improvment pics the unit and wonder pics are fine though.

[Ekmek]

the pictures and mice should be studd you put on the hard drive in /ctp2_data/default/graphics/

[lynx_abraxas]

I have to guess what You want to say. Do You mean the pics are wrong?
Well, checking this, I noticed only svn-images have these artefacts. Using gimp to see if these pics are in 16bpp I got 24bpp as an info but that might be not for sure.
I failed badly when trying to convert CM2_UPIP031L.TGA to 16bpp. There seems to be no tool for linux that can do so. I checked gimp, convert and a pythonscript (this didn't run).
I also wonder where the original pics are stored. One unit pic should be named UPUP002L.TGA but is no where to find. Is there an archive for those?

[Martin Gühmann]

Originally posted by lynx_abraxas
Is it already possible to add options with parameters, like -g 1024x768?

Why would you want something like that? The screen resolution is stored in the userprofile.txt; the screen resolution should be read from there as the windows version does it.

Originally posted by lynx_abraxas
I tried two nights now finding this artefact bug in the cursor and the improvements building queue. I first suspected a wrong chroma key but now having investigated this further I think it is a bug comming from AUI_SURFACE_PIXELFORMAT_565 being mistyped somewhere as AUI_SURFACE_PIXELFORMAT_555. Also g_c3ui->Primary()->PixelFormat() in civ3_main.cpp is giving me greef. It returns the wrong AUI_SURFACE_PIXELFORMAT which should just depend on g_is565Format.

So why don't you fix this bug. I am sure Linux has a little handy feature used for searching files with a specific string.

Originally posted by lynx_abraxas
Observing the svn revisions, only changes are done at /trunc at the moment. Are those modifications for bringing the /trunc to sync with /branch/linux or are there also modifications added to /trunc that aren't in /branch/linux?

What do you expect? Something like everyone has Linux installed on his computer so that everyone can test his changes made on the windows version also work on the Linux version? Obviously not. And if noone works on the Linux version then only changes are added to the windows version. That's it. Obviously it was a bad idea to have two branches there. The Linux branch should be merged into trunk and then MSVC compilability on windows should be restored and then also the Linux compilability. There is two much additional work for keeping the branches in sync.

Originally posted by lynx_abraxas
The screenshot You posted in http://apolyton.net/forums/showthrea...63#post4046963
shows no sprite. Which should be fixed but isn't continueously. Sometimes they vanish when having finishe their animation. Exception is the Phalanx it stays visible and seems to have a chroma key set somewhere extra. (very strange)

I think this is fixed for the windows version.

Originally posted by lynx_abraxas
Forgot: How did You take the screenshot? Is there a function like in CTP1 with the print-key?

That is a windows function, therefore you won't find any code in the game for that. But of course you can try or you have to wait for John to anwer that question.

Originally posted by E
the pictures and mice should be studd you put on the hard drive in /ctp2_data/default/graphics/

No E, he didn't ask you where all the stuff is stored on the hard drive but where is the code located that the stuff draws. And that can be found in the /ctp2_code/gfx/ folder and in its subfolders for the map and the UI stuff is in /ctp2_code/ui/ espeacilly those aui_* subfolders.

Originally posted by lynx_abraxas
Well, checking this, I noticed only svn-images have these artefacts. Using gimp to see if these pics are in 16bpp I got 24bpp as an info but that might be not for sure.
I failed badly when trying to convert CM2_UPIP031L.TGA to 16bpp. There seems to be no tool for linux that can do so. I checked gimp, convert and a pythonscript (this didn't run).

You shouldn't mess around with them, they work fine on the windows version and are made with Paint Shop Pro. Those are 16 bit targa files and not 24.

Originally posted by lynx_abraxas
I also wonder where the original pics are stored. One unit pic should be named UPUP002L.TGA but is no where to find. Is there an archive for those?

Yes, there is an archieve for them it is called pic565.zfs and you can find it at the other images. But even if you open it you won't find targas in it but rim images. The game checks for targas first if there is no targa version it checks for a rim from the archieve.

-Martin

[J Bytheway]

Originally posted by lynx_abraxas
The screenshot You posted in http://apolyton.net/forums/showthrea...63#post4046963
shows no sprite. Which should be fixed but isn't continueously. Sometimes they vanish when having finishe their animation. Exception is the Phalanx it stays visible and seems to have a chroma key set somewhere extra. (very strange)
At the time You took the screenshot, did the game continue?

I may have played a couple of turns more, but I doubt I did any serious testing.

Observing the svn revisions, only changes are done at /trunc at the moment. Are those modifications for bringing the /trunc to sync with /branch/linux or are there also modifications added to /trunc that aren't in /branch/linux?

There are lots of changes in each but not the other. It's an unfortunate situation, and one that has been discussed quite a lot in this thread.