Nightly builds, here they come

Hi everyone,
let's interrupt the flow of GSoC updates for a special announcement!

If you hang around with us in IRC you've probably noticed that Xeli set up a nice buildbot system that automatically compiles the latest version of Hedgewars and checks if each commit breaks a particular configuration (not that it ever happened Wink Smiley )

One of the amazing thing of our configuration is that we were able to setup a full platform check for Linux, Android, Windows and OSX (iOS might come up later on). Windows is compiled from unc0rr's machine through WINE while OSX is actually crosscompiled from Linux (yeah, we're officially in the club "I managed to crosscompile for Apple, yo!")

Today we bring this to a step further, nightly builds are available! Now our buildbot prepares some easy packages for every platform, so that you can live on the bleeding edge and try our new exciting features before official release! Getting some early feedback will help understand the community position on certain design decisions and also improve our release capabilities, by spotting and (hopefully) fixing bugs before an actual release.

So, don't waste any more time and head to http://xelification.com/nightly/

Koda Flying

Insert standard disclaimer clause here: nighly software is completely untested and unsupported and might not play nice with your current profile, so make backups as always!

GSoC project: Hedgeroid Netplay - frontlib progress

Hello again.

Over the last weeks, I have been busy working on the new frontend library (frontlib for short), which is written in plain C for best portability. By now, the scope of the library has become clearer, so I want to give a short overview of what it will look like, what already works, and what still needs to be done. As you can see in the image above, one of the things that already work is the map preview rendering.

In my last blog entry, I wrote that there would be a function for each kind of message that could be sent to the engine or the server, and a callback function for each kind of message that could be received. Since then, I have become convinced that this low-level approach is not a good idea, since using a library with that API would not actually save much work.

The first important change is that the frontlib now contains data structures that can hold all important game configurations: The choice of map, team and hedgehog information, game and weapon schemes. It can also read and write .ini files with these settings, so it now handles more than just networking.

As a consequence, the frontend can now quickly build a game configuration by loading weapon schemes and other settings from .ini files, and then ask the frontlib to pass this entire configuration to the engine. The same data structures will also be used for netplay communication, so it will be easy to tie everything together and e.g. start the engine with game settings received from the server.

To start a new game, the frontend can now pass the entire configuration to the frontlib at once, and let the frontlib work out how and when it needs to be sent to the engine. Likewise, the callback functions have changed in keeping with this higher-level approach.

Hi everyone!

Time for this weeks A&O.

I've pretty much finished upgrading everything thats relevant to GL2+ and GLES 1.3+.
Meaning we should be more or less ready for ES2.
For the water rendering (It really just was a vertical gradient), I've added a seperate shader.

The only stuff thats still missing to be upgraded is the stereo draw mode.

For this week I've planned starting to finally integrate the rectpacker into the engine.
Both modes, GL2 and the original FFP GL1.x mode should benefit from this, as this reduces
the amount of times textures must be changed.

I'm as well trying to get an ES2 emulation layer on my desktop in order to find the last missing pieces, keeping the GL2 version incompatible.

GSoC Project: A New Adventure - Update #1

Hi everyone!

The first milestone in the campaign creation phase is over, so it's time for an update.

The first step in creating a campaign was allowing certain variables to be passed between missions so that the story could modify based on the action taken/decisions made on previous missions. It is now possible to save and request these variables from within a Lua script by calling SaveCampaignVar and GetCampaignVar. The first function takes two arguments, the variable's name and its value, and creates/modifies an entry in the selected team's ini file, in the section corresponding to the campaign. GetCampaignVar takes a single argument, the name of the variable and returns a string value, so it is up to the creator of the script to convert it to whatever type necessary. It is also required that the progress is modified if it is the case.

In order for a new campaign to be added to the game, a directory with the name of the campaign needs to be added in Data/Missions/Campaign. In this directory there has to be a campaign.ini file and scripts for each mission. campaign.ini has to contain the following lines:

MissionNum=number_of_missions
ResetRetry=1 or 0 // whether the progress should be reset in case the player decides to retry a previous level

In addition to these, there needs to be a section for each mission, containing its name and the name of the script (Name and Script).
For example:
[Mission 1]
Name=Ultimate Hedge Mission
Script=ultima.lua

The next step was creating a frame for the story of the campaign. The story in its current state can be found at the links below. Suggestions are welcome!
SPOILER ALERT!
http://dl.dropbox.com/u/69740901/HWStory.odt
http://dl.dropbox.com/u/69740901/HWStory.doc

Hi everyone!

As promised last week, we now have a GL2 version that uses GLSL 1.20 shaders (with a few compatibility propfile features) to render everything.
I've as well replaced all projection related code by using a plain uniform matrix.
This is an essential step towards the non FFP using GLSL 1.30+ transition, which we will need for ES2+ or GL3+ only systems.

So far everything, but the water rendering, runs smooth.
I did not decide, yet, if I shall honor per vertex coloring for all sprites or if we'd have
an additional, independant render pass for the water, as only the water requires this feature.

By next week I hope to have a fully functional GLSL 1.30+ pipeline.
The major changes involved here, are replacing all gl*Pointer stuff with attributes,
as well as removing some leftover FFP state as glColor to uniforms.

Once this is done I'll need to rewrite the stereo rendering, which, due to using quite some FFP, is most likeley broken at the moment.
At that point we should pretty much have forward and backward compatibility ranging from GL1.1 to GL4.x and I can finally start with the actual atlas optimization, which I already prepared two weeks ago.

Syndicate content
facebook twitter

User login

Server Stats

Rooms: 2
Players: 3



Copyright © 2004-2021 Hedgewars Project. All rights reserved. [ contact ]