Beta Galactic Artifact - Release B


zear_ said:
Trevor Bradley said:
You willing to risk a dynamic one and have to hunt around or compile your own libs?
Well, yes :D
I use Gentoo anyway.

Of course I'm not forcing you to compile a linux version if that's a problem.
I could just try to run it via Wine or something.

I dunno how many people have tried this game on Linux, or Wine for that matter, but Wine works for me with each and every revision (A, B, and the two test releases) (and I haven't tried the latest Test Release, but it can't be that much different haha).

Simply a stock install of Wine on Linux Mint (the same one found on any Ubuntu system I presume), and works fast enough... same speed as I got on the Linux version of Revision A, if not 2-4 FPS better.

I suppose you could take the route of uTorrent (windows-only but with a focus on Wine compatability), but that would kinda exclude the Pandora... so scratch that! It should work for any Linux user with an x86 machine capable of Wine for the time being, though...

--q
 
Last edited by a moderator:
Trevor Bradley said:
OK kids, do NOT do this in your for loops:

CODE
if (alien_match) {
for (int i=0;i<(int)visible_alien_stars.size();i++) {
for (int i=0;i<(int)visible_alien_stars.size();i++) {
I'm seeing some serious radar speed improvements now... :)

At the center of is all I get 27 to 33 fps, even one backed out. Way better, but when I select or move to another star, it freezes up for about a second.



Trevor Bradley said:
...first download the new version...

I skipped the 273 and went straight for the 280, I hope it doesn't matter.
Trevor Bradley said:
give me specific instructions on how to reproduce the red area bug, such as:

Artifact is in Sector 9
Get Futurist Artifact
Go to Sector 8
Use Futurist Artifact.
Go to Sector 855-5550
Red area gives x FPS.

Ok, here:

Artifact is in Sector 6
Get Futurist Artifact
Go to Sector 8
Use Futurist Artifact $$$.
Go to Sector 855-5550
Red area gives 17 FPS.

CODE
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 1 Radar Surface 1 Information Surface 49 Flip Screen 5 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 1 Radar Surface 0 Information Surface 49 Flip Screen 5 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 1 Radar Surface 0 Information Surface 51 Flip Screen 5 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 1 Radar Surface 0 Information Surface 49 Flip Screen 5 Before Delay 0



Then I used a few random artifacts,
Sector 855-5550
Red area gives 16 FPS.

CODE
Begining Loop 0 Basic Surfaces 2 Galaxy Surface 0 Radar Surface 1 Information Surface 52 Flip Screen 5 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 1 Radar Surface 0 Information Surface 52 Flip Screen 6 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 1 Radar Surface 1 Information Surface 52 Flip Screen 5 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 2 Radar Surface 1 Information Surface 52 Flip Screen 6 Before Delay 0


Hmm, with just one artifact it gets pretty bad, then a few more and it barely gets any worse.


(Oh, and what about making a few upgrades over 10, but only for speed and drive, but cost a ridiculous amount. Like $200 for lvl 11, $400 for lvl 12, $800 for lvl 13, $1600 for lvl 14 and $3200 for lvl 15. You get the picture, that way no one gets to max everything, there is always more, its just not worth it.)

Edit:
Also, in the middle (555-5555), in the red-zone, with maxed radar. 10 FPS

CODE
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 3 Radar Surface 34 Information Surface 61 Flip Screen 5 Before Delay 0
Begining Loop 1 Basic Surfaces 1 Galaxy Surface 2 Radar Surface 30 Information Surface 55 Flip Screen 6 Before Delay 0
Begining Loop 1 Basic Surfaces 1 Galaxy Surface 2 Radar Surface 31 Information Surface 54 Flip Screen 7 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 2 Radar Surface 20 Information Surface 56 Flip Screen 5 Before Delay 0


And zoomed out once:
CODE
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 2 Radar Surface 18 Information Surface 54 Flip Screen 5 Before Delay 0
Begining Loop 0 Basic Surfaces 2 Galaxy Surface 2 Radar Surface 16 Information Surface 55 Flip Screen 6 Before Delay 0
Begining Loop 0 Basic Surfaces 1 Galaxy Surface 2 Radar Surface 17 Information Surface 54 Flip Screen 6 Before Delay 0
Begining Loop 0 Basic Surfaces 2 Galaxy Surface 1 Radar Surface 16 Information Surface 55 Flip Screen 6 Before Delay 0


Before the radar was 200, now its 30. Very nice job on the new code. But now the "Information Slice" (aka: red-zone) is wasting more.

I hope you can fix that too. But we all know that removing unnecessary vertexes and redefining polygons has always been extremely complicated. When all else fails, we layer.
 
Last edited by a moderator:
Themonkey, i got it while online, with no lag. i think its just when you try zooming or panning really fast.
 
Well Monkey, I did the research and found out what the delay was.

First of all on my fast computer my information surface is rendered in a fifth the time yours is, in about 11ms. Still, I dug down and found out what that problem was.

It's not a layering problem, as the layer is produced once and then saved as a surface. Nor is it a calculation of information, or drawing of information.

The problem is entirely blitting a translucent surface on top of the star data. I don't see any efficiency blitting with an alpha of 127 instead of 63.

The solution I think is to blit the information surface underneath the stars, with no alpha. It will look different, possibly look really bad, but I think I can play with it to make it look semi decent.

Gimme a while to see if I can make it work.

EDIT: Reversing the order of the Information and Galaxy surfaces makes the Galaxy loop like crap because of the Galaxy background image. I'll need some serious time to think about it.

There was some guy on #sdl saying that Alpha blitting was horrible and that there are more efficient ways of doing it. Seeing as how there's only one color to alpha against (black or dark red), it might be possible to make a fast-alpha blit.

The green border of the information already scans through the surface and takes almost no time to create a new surface. Let me restore the Galaxy/Information surface order and attempt to write my own alpha bit function.
 
Trevor Bradley said:
...blitting a translucent surface on top of the star data...
Ohhhhhhh (epiphany). Its the translucency. Now all this time I assumed that just making it transparent was simple.

Trevor Bradley said:
...attempt to write my own alpha bit function...
Cool, I'd just remove the blue and green bits. Or change the write buffer by personally adding to the red bit before its sent to the screen.

Edit: Which are both, of course, completely wrong.
 
Last edited by a moderator:

Wow, this picture of inhabitants is great! Can't wait for separate pictures for the each "race".
Also, it's running fine on linux.
I'm gonna tar.gz the working libs for all of you who can't get it run later today.
 
OK, more on the red area.

I had a good think about this for a couple of hours and was about to put the whole thing off to Release D, but I think I have a solution.

Right now, everything is rendered in layers. From the bottom to the top:

Galaxy Surface
Radar Surface
Information Surface

These can be broken down even further:

Galaxy Surface:
* Black background
* Spiral galaxy glow (the jpgs in the sheets directory)
* Stars
* Ship Cursors
* Green selection Cursor
Radar Surface:
* Pie arc or circle for radar
* Alien radar signal
* Artifact radar signal
Information Surface:
* Red information surface
* Green information outline.

Previously, the Information surface needed to be updated constantly, as the Radar surface was underneath it and was updated each frame. The Red information surface, rather than having a colorkey transparent background (think a transparent gif) which is really fast to render had an alpha setting, which is very slow to render.

At first I tried to move the Information surface below the Galaxy Surface, but it looked awful. Then I tried to convert the red information surface from SDL proper to SpriG, which gave me a huge boost in the galaxy zoom earlier, but that turned out horribly. SDL and SpriG represent their colours in reverse order (big endian, little endian) and a proper conversion to SpriG would mean updating the whole application.. would take a week at least.

So I had a thought about it, and realized I could put the information surface between the Galaxy Surface and the Radar surface. That way the information surface would only have to be updated during the panning or zooming, but not while the view was stationary.

This however, doesn't fix the awful fps while panning. However, something PoisonedV said made me remember something TheMonkey said... that the pan takes too long to snap in place. This is because the pan, unlike the zoom, is keyed to the frame rate, rather than the actual time. So a zoom would have horrible fps, but wouldn't affect the speed of gameplay. While a pan with bad FPS takes too long.

I actually had "Key Pan FPS to time instead of framerate" on my list of known bugs for Release B. Rather than putting that off, I'm going to fix it for this release. So you'll have a crummy fps while zooming or panning, but it won't slow down the game at all.

So I'm going to do the following for Release C:
1) Move Information Interface before the radar interface to improve fps while stationary.
2) Key panning speed to time, rather than framerate, so that panning occurs at the same rate for everyone regardless of fps.

That's all I'm going to do with the Red Area for this release, as I've still got a handful of other Release C bugs and upgrades I've not been able to tackle yet.

The real solution to FPS might be to move to SpriG, or to OpenGL. But I'm not really going to be able to determine that without a lot of out of game testing, and honestly not really until I get a Pandora in my hands. :) Release D or later.
 
Good to hear that a solution is in the works :D

Trevor Bradley said:
...The real solution to FPS might be to move to SpriG, or to OpenGL...
Probably for the pc release, but I thought that the Pandora was only going to support SDL. Maybe I was mistaken and they meant the button inputs were with SDL, the graphics could use OpenGL. Or maybe you can use anything, but compile it for the Pandora. I'm soo confused.

Also:

QUOTE
...key panning speed to time... ...but wouldn't affect the speed of gameplay...

Sweet! Now my speed rush is left unhindered even while panning.
 
Last edited by a moderator:
The picture with the Future Guy looks great. I haven't tested the new version but I can imagine it would look very nice in action. I alo could imagine some TV-noise when the picture appears, pure cosmetic of course :D

I want to remember my little bug, where I couldn't end the game. Maybe this was because of the new included .dll, I don't know. I have to test the latst release to find out.

I also would like to know, if my Idea of a coloured text for the sell /buy screen for Artifacts is useful for the game. I can imagine it would seperate the different races better during selling the Artifacts but this has to be tested in the game. :)
 
Another no-win. I got the artifact and nothing, no countdown. It was around 2:12am PST. If it helps, I think it has something to do with how long it takes, my time was over 15 minutes. When I get it with cheating, it always gives me the win, but without cheating, it takes 10 to 15 minutes (more if a really unlucky start eg: no Industrialist for 5 minutes).

Edit:
When I just tried to login, it just gave me an "Unknown server message" with some numbers, grouped in tens. Then I tried again, and it let me connect like normal.

Edit2:
The no-win bug might have something to do with clicking out of or pressing enter to leave the "You Win" screen before it has a chance to fully load all the text.

If I wait too long after the appears, it won't give me the win. Sometimes unless I wait till all the "You win..." text is exactly half-way loaded before I click enter, for it to let me win.
 
Trevor Bradley said:
http://games.randomlynx.net/GalacticArtifa...ct0282-TEST.rar

Should fix red area bug. Cursor and pan speeds now both tied to real time instead of fps. (Green Cursor might be too slow now)



Lol, the screen gets twice as red when I get a new hint. Then it goes back to normal if I pan away, and back again.

Edit:
At 555-5555, I get 25 to 33 fps IN THE RED-ZONE, WITH MAXED RADAR! (sorry for yelling, but it is a big improvement)


Edit2:
When I move the cursor by clicking the mouse once, or move the ship by clicking the mouse twice, the fps drops to 0 for about a second.

But, when I move the cursor with the keyboard, or move the ship by pressing enter, I still get 25 to 33 fps.

Something is hay-wired with the mouse select code. I wan't to call it "mouse lag bug".


Other than that, WAY WAY WAY faster fps than before. It doesn't look like you fixed the "pan to time" thingy yet though, but this red-zone bug is way way better.
 
Last edited by a moderator:
fusion_power said:
The picture with the Future Guy looks great. I haven't tested the new version but I can imagine it would look very nice in action. I alo could imagine some TV-noise when the picture appears, pure cosmetic of course :D

I want to remember my little bug, where I couldn't end the game. Maybe this was because of the new included .dll, I don't know. I have to test the latst release to find out.

I also would like to know, if my Idea of a coloured text for the sell /buy screen for Artifacts is useful for the game. I can imagine it would seperate the different races better during selling the Artifacts but this has to be tested in the game. :)
The coloured option text is an excellent interim solution for determining which icon type is which. The options are done rather primitively at the moment, but I might be able to squeeze this in.

TheMonkey is also finding bugs with win not working. I was able to inconsistently reproduce it by quiting the victory screen too early. An early look at the code is even more confusing, as the victory screen isn't even displayed until the victory message is sent to the server.

I'll have to a closer look tomorrow.

Or I could be dumb... Just because a message is queued doesn't mean it's sent (code author needs sleep)

http://games.randomlynx.net/GalacticArtifa...ct0283-TEST.rar

Should fix TheMonkey's No Win bug.. dunno about fusion power (worth testing).
 
Last edited by a moderator:
Trevor Bradley said:
I was able to inconsistently reproduce it by quiting the victory screen too early.
Yeah, that's the problem, no matter what I do, it just seems to be random. Maybe the time you leave the "You Win" screen has nothing to do with it after all. I just tried a bunch of times, nothing makes sense. Maybe someone on my lan is bit-torrenting or something...

Without clicking or exiting the screen at all, I just won a few and lost a few...
And just now I won a few and lost a few by exiting as quickly as possible...

Nope, I was wrong, it doesn't seem to make a difference. Ill keep looking, cause a "no-win" is a bad thing.

edit:
I just tried like 20 times to win, but lost every time. Its 3:52 PST if that makes a difference. Maybe the server logs will help.

After quitting the program, and reloading it, I was able to win on the second try. But that also could be random, I'm just grasping at straws right now, its definitely in the code.

Oh, and thanks for fixing that second window bug, I don't think anyone even noticed it missing.

Edit2:
QUOTE
...Just because a message is queued doesn't mean it's sent...

Could you make it send the win a few times until the server sends a message back letting the client know it got the message? I'm sure that would solve things nicely. Then again, I don't know if you already have a better solution in mind.

(On a side note, I type a lot of nonsense, then unequivocally I strike gold. I hope you read all my posts, sometimes I break the rambling to shed light on something important, I hope nothing important I said was overlooked. Partly because I can't personally tell the difference between rambling and something important. Maybe I just need sleep.)
 
Last edited by a moderator:
As promised here are the libs that work for me:
http://zear.shfx.pl/publiczne/linux/ga-libs.tar.bz2

libvga is the one included in Galactic Artifact release A
libsprig is from the official site
You have to create symlinks yourselves.

I didn't have problems with the rest of the required libs under Gentoo, so i guess there shouldn't be problems with other distros, so you can simply grab them from your repos.
 
TheMonkey said:
QUOTE
...Just because a message is queued doesn't mean it's sent...

Could you make it send the win a few times until the server sends a message back letting the client know it got the message? I'm sure that would solve things nicely. Then again, I don't know if you already have a better solution in mind.

(On a side note, I type a lot of nonsense, then unequivocally I strike gold. I hope you read all my posts, sometimes I break the rambling to shed light on something important, I hope nothing important I said was overlooked. Partly because I can't personally tell the difference between rambling and something important. Maybe I just need sleep.)
There is one more thing I want to fix... Right now I've attempted to override a setting: TCP_NODELAY that would guarantee messages have been sent. Normally it's a tradeoff to ensure the messages aren't blocking other threads. No reason to do this now that the messages are being threaded.

And I do read everything here! It's just getting a bit overwhelming for me too, and I parse and then forget really good ideas like the coloured option list.

TheMonkey, can you test the new 283 binary to see if the win is now consistently working when you have a sec?

I'll have to check that new minor "double red" bug. I swore I fixed it.

EDIT: The mouse pan delay is because it's ignoring all mouse input until the pan completes and the frame "clicks" into place. This needs lots of tuning as it's an all new algorithm. I'll make a note to verify this is still working.

EDIT2: Yea, the mouse is definitely hosed with this latest release. I'll add it to my list. :)

EDIT3: And hitting enter too fast on the victory screen still causes a "no-win" scenario even with the latest update.

EDIT4: OK, I know for sure what's causing that no-win problem, as well as a lot of dropped text messages. Might need to test this on a laggy connection to make sure it's working for all. still happening.. give me some time to fix this properly.
 
Last edited by a moderator:
Trevor Bradley said:
And I do read everything here! It's just getting a bit overwhelming for me too, and I parse and then forget really good ideas like the coloured option list.
No problem. :D
To be even more onto the save side, there could be one Menu for buying and one for selling so you don't sell a valuable artifact accidently if you just want to buy a update straight underneeth. (happend to me ^_^ )
 
Last edited by a moderator:
I need a brave soul... Ideally someone with a sizeable (100ms+) ping to my server.

Can someone do the following for me:

1) ping games.randomlynx.net and tell me what your delay is
2) Download the following:

http://games.randomlynx.net/GalacticArtifa...factNetTest.exe

And place it into your GalacticArtifact directory.

Run that application, start a network game and then do NOTHING for 10 minutes. No ship movement, no texting, just let it sit.

When 10 minutes have elapsed, hit escape and quit the application, and then upload stdout.txt here. You'll probably want to zip it as it will be about 10000-50000 lines long.

What I'm testing here is network integrity. I've determined that I need to time the client and server just right so that no packets get lost. I've done testing through my own ISP, had two machines hammer the server simultaneously. My latest test had 24000 messages sent by two computers, none lost. But the ping to my server is 1ms and I'm not sure if the setting will work for other network players.

Thanks so much. Hopefully this will clobber no win, message and ship data loss for good.

EDIT: My laptop also has no data loss to my wireless router, up to the ISP and back, but the ping is only 1.73ms. Damned reliable network connections.

EDIT2: Hold off on this.. Did some testing with zear in Poland, got some interesting results.
 
Back
Top