New client roadmap (1.5.0)

[Entropy]

This thread is for PROGRAMMERS WHO WORK AT THE GAME ONLY, please no suggestions, questions, etc. For those questions, create a new thread!

 

Everyone who is planning to do something new, please post here about what you want to do, and how long it would take. Ideally, the new release should be in November, so please make sure your new features can be implemented, tested and debugged in this timeframe.

 

Here are the things I would like to be added in the upcomming client:

1. Arrow/Missile support, client side.

2. Landmines and explosions (the landmines will be sent in a similar way with how the bags are sent).

 

Since those two things are going to need server support, whoever wants to work at them needs to coordinate their effort with me.

[KarenRei]

For now, I'm just working on integrating eye candy support with the map editor (it's proving to be quite the effort ). After that, I'll work on other eye candy related issues (new effects and options, integrating effects not hooked in, etc -- ie., get them all done). After I finish with the map editor, I'll post in more detail about the effect work to be done and detail what I plan to work on after that (lighting, normal mapping, shadow volumes, etc) in more detail for discussion.

[ttlanhil]

some of this is already in the client and just needs finishing, or I've talked to Ent about it already... some of it will need his blessing before I go further into it I've got approval to work on all this so far

 

I intend to get the NEW_WEATHER stuff working well. - Done. Or at least, the problems that stopped it working are fixed, so it's back to how it used to be. Will need to wait for the server to use the new protocol before we can be completely sure, but it should be a go (the server should be able to use the new protocol for the old weather as well, the handler for the new weather protocol is implemented for old or new weather systems)

 

if no-one else picks them up, I'd like to try to update/finalise the minimap code, new_sound, the notepad (Torg), and ezzat's follow-cam/skybox/etc.

It's be great if the authors could work on this, or if someone else wants to help out, but if not I'll see how much I can get working well

I have no idea how long any of this would take.

 

texture recolouring, set by server (as in the thread where everything was green).

this one will need some network protocol done, but the client-side code should take only an hour or two (as most of the code is already provided by karenrei's nighttime recolouring)

ed: After talking with Xaphier, it looks like he'll be rewriting the NEW_LIGHTING code to use shaders, where possible, so I'll probably just do a bit of work with him and/or ent to plug things together and do the network handler

 

announcement/warnings for new hour, dusk/dawn, and new day. in client, instead of provided by a (large) number of bots Done.

 

extra stuff:

I'd also like to move the file opening stuff out to dedicated functions. this would mean open_data_file(), open_cfg_file(), and open_translatable_file(). Done.

doing it like this means all the OS specific stuff is in one place, and the failover to English is also only done once.

this wouldn't take long to do, but will require changes in a lot of places, which may cause issues for other developers if they have a heavily modded tree

 

related to this, to be able to do auto-update even if you don't have write permissions. Done.

This would be done by downloading into ~/.elc/updates or similar. this is only practical with the above suggestion, since those functions can check for a newer version in ~/.elc first

and if the version in DATA_DIR matches the checksum, delete the one in ~/.elc since it's no longer needed.

this would also mean, however, people could copy changed files into ~/.elc/updates , set them read-only (so the updater doesn't delete them or update them) and have modded textures, etc, without having to move away the ones in DATA_DIR

 

also, a general cleanup in a lot of other places. there's probably a lot of functions we don't need to have.

Since we have to link with stdc++ now anyway, we might be able to wrap some of the STL functions, and simplify the code. dependant on performance, of course. investigating this will take a fair bit of time

 

I'd like to remove the server address/port settings, and replace them with entries in a file (servers.lst maybe)... right now with only one main server it's not that big a deal, but it means no more failing to connect because you had the mouse over the editbox when you pressed a key, etc.

also, if there ever is another server address change, this file could easily be auto-updated.

one thing that may be either good or bad is that it'll be a lot easier for people to get on the test server... including those who can't write a good bug report

for this to work well, it'd need an option to select which server on the login screen (and maybe even have the servers respond to PING before login, so you can update ping times... if you want to be fancy...)

if/when we get more servers, this will become more important

If this is done with a list of servers on the login screen then it'll mean a bit of Roja's time to do the design, but the code itself should only be a few hours worth

 

I'd like to make ripples in the water. <description deleted too>

 

Better URL management in the client. Done, currently using #url, soon to use a window as well.

There's patches for this already, so it'd be a quick job to update them. this would mean that you can access more than just the last URL (as anyone who's tried to launch web browser, but seen someone else post a link in the meantime knows... this would be handy)

there's a pretty recent #url textual patch, and an older one that uses a window. older one would take a little longer to bring up to date, and would need a console button of its own, but I imagine most people would find it easier to use

 

I'm also thinking that a #bug command would be helpful... it would dump to file the coords, map name (maybe also a checksum of the .elm so we can tell if the problem is because they're using the wrong file), all the info you see on the screen with -DDEBUG, many of the config options, compile options, etc etc... it wouldn't be perfect, and users would still have some issues with finding the file to copy to forums, but it could come in quite handy at times

Edited June 29, 2007 by ttlanhil

[Entropy]

Don't start working at the water ripple:

1. We plan to have a new geometry in the game (height maps rather than tile maps)

2. It will be done with shaders.

[ttlanhil]

okay, cool. the actual impacts would be the easy part (collision of footstep and raindrop), which I'm qualified for, so I'll probably talk to whoever then.

 

oh, one of the things I wanted to add to new-weather was use of particles for the rain/snow that's close to the camera (and continue using GL_POINT for the rest).

[Entropy]

Well, try it and see how it looks like. I don't think that particles are necesary for the rain, but they should look nicer for the snow.

[Torg]

if no-one else picks them up, I'd like to try to update/finalise the minimap code, new_sound, the notepad, and ezzat's follow-cam/skybox/etc.

It's be great if the authors could work on this, or if someone else wants to help out, but if not I'll see how much I can get working well

I have no idea how long any of this would take.

I'm not the original author, but I was reviewing, testing and committing the -DNEW_SOUND code so I'd be happy to pick that up and see what I can do.

 

I am at this stage unable to test under Windows, but that was meant to be mostly stable, with most of the work required under Linux. Unfortunatly for the OSX devs (0ctane you rock!) and players I am also going to struggle to support that build.

 

I have also been interested in the notepad, so given ttl has such a large workload already, I'd be happy to work on that unless someone else is interested.

[Xaphier]

I plan a bit code cleanup. I plan to remove NEW_E3D_FORMAT and NEW_FRUSTUM flags, so they are always used. I also pan to remove USE_LISPSM, TERRAIN, USE_LOW_MEM, USE_SHADER, USE_SSE, USE_SSE2, SSE_SSE3 and remove their code so they are not used, because they are buggy. (files sector.c, sector.h, normals.c, normals.h, normals_low_mem.h, normals_sse.h, terrain.c, terrain.h, simd.c and simd.h disappear)

Next things are adding support for jpegs, pngs etc. as texture formats using sdl-image and get the texture cache working, then graphic card extension tracing (sending these information to the server so we know how man users have which extensions) and support for "texture combiner scripts" (xml files where you can control/modify texture combiner use).

After that I plan to write 3d terrain support with normal mapping support.

Edited June 9, 2007 by Xaphier

[bluap]

I'm not an official dev but I hope I can still post here.

 

Having submitted the recent #url patch I'd like to see that committed; I'll check the code against current CVS and update as necessary just in case. I said before that I'd look at updating the url selection GUI patch too and I'll happily still do that. The command line version and the GUI should easily live together and use the same url catcher code.

 

Judging by the way the RC testing went, I think we might benefit from some checking on the data_dir path being used. I haven't thought through a full solution but it may require some information from the server to be compared with information in the client data directory. I'll investigate further if people think it would be useful. The proposed #bug command sounds like a great idea to help with this sought of thing BTW.

 

For may be a year I've had issues with sound for a client built from CVS; lock-ups, stuttering etc. The previous release static binary worked fine so I assumed it was my setup. I presume my problem is due to library version issues. Dependencies on my system (Debian Etch) forced me to update the libalut-dev package to version 1.0.1-1. Debian is hardly cutting edge so if this is the problem, may be we could update EL to use the newer version. Hopefully, the new release version still works, if so I wonder what library version is used for that build... If people want this done, and it can't be included in the other sound work, I could work on it.

 

I'd like to see and help with some user interface refinements: I'd be interested to hear what happened to the new spells interface and if anyone has picked up the guild command GUI work.

 

One idea I have is for a generic right-click context sensitive mini-menu - pops up where the mouse is. It could be used in many places, for example, selecting an action on items in your inventory, on the tabmap marks, the spells quick bar, even when selecting an action such as fight, use, look, trade etc. I have some ideas about the implementation so I'd be interested if people would like this feature.

 

Generally, I'd be happy to help where help is needed. Entropy's items sound a bit large for someone like me to take on. If the tasks can be divided into smaller pieces of work I could help. ttlanhil, are you looking for volunteers for your list of things?

[LabRat]

I want to make the EL window completely resizable, I have played with just that and it won't be too difficult.

 

gl_init.c:0336

	flags |= SDL_RESIZABLE;

enables resize, now I just need to clean up all the very minor issues the line causes:

• hud misalignment (icons in wrong place) until the client switches to the console or map window
  
• in console view the text editing box is misaligned
  
• rewrap the text to fit the new window size
  

I will also need to code in an absolute minimum window size (640x480), and alter the code to allow the hud items (digital clock, statsbars etc) to display if there are enough pixels in height

 

An idea suggested by someone else was to have a look at merging my work with the resizable hud icons, I may well consider that too.

 

Pretty much all of the work is already done in code, I will just need to hook into it when the window resizes.

--------------------

Clicking on the Maximise icon is a lot better than dragging the EL window into place at game startup, and a lot quicker too

Edited June 6, 2007 by LabRat

[Entropy]

I think there was a reason I made it unresizable, but I forgot why. If it works fine, I am all for it.

[Roja]

if no-one else picks them up, I'd like to try to update/finalise the minimap code, new_sound, the notepad (Torg), and ezzat's follow-cam/skybox/etc.

 

Just thought I should comment on this. I contacted emajekral back in January or so, asking if he planned on finishing it, or if not, if he can release his code for other programmers to finish it. He told me he would work on getting it ready to release it. He never did, I emailed him 2 more times in the following months and got about the same reply..he sounded like he was busy irl but he'd do it soon. Still haven't heard from him and I did email him, one last time, at the beginning of this week.

So, things don't sound promising

[ttlanhil]

some of emajekral's code is on berlios, though I expect it's not the latest...

if we can get the latest from him, I can work on getting that up-to-date and in CVS, so people can test and tweak it (including as much of his work as he has time to add)...

failing that, I'll use what's on berlios, as at the least it's a step forward from where we are now

[0ctane]

Hi folks. Most of my efforts will be towards fixing your code. Just kidding. Fortunately, most of the endian issues only arise from server messages, so please keep me informed about any new data being sent to the client. I will actually be trying to get a lot of the OSX graphics problems fixed. This will involve figuring out why framebuffering and (maybe by extension) shadow mapping is not working properly. Although, my PowerPC test system at work only has a ATI 7500, so no frame buffer support there.

 

[edit]I should mention that I will probably be asking for assistance on some of the OSX issues. Most of you have kindly assisted me in the past.[/edit]

 

On the good side, I have some guinea pig client testers (hopefully more will volunteer), and I will soon be commiting code that will make building the OSX universal binary a bit easier.

 

My long term goal is to make the client much more Mac native (less SDL), but that might take a few extra game versions to complete.

Edited June 9, 2007 by 0ctane

[KarenRei]

Less SDL?

 

... why?

 

I don't relish the thought of more code I can't test. It's been a big problem with the map editor, which has much of the same functionality implmented in native Windows code and GTK. I can only develop for the GTK side.

[0ctane]

Less SDL?

 

... why?

Well, if I can get the keyboard input to be native (SDL prevents keypresses from going to the OS), then Mac users can use their speech recognition functionality. This would fall better into line with the universal accessibility goals of Macs. Plus, it would be darn cool to say "open inventory" instead of the keyboard shortcut.

I don't relish the thought of more code I can't test.

At least your computer does not completely freeze when you try to activate shadow mapping, right? A bit hard for me to test and fix that problem. Besides, I am usually just playing catchup ... trying to get all the stuff you guys create to just work on a Mac. Anyhow, it would just be related to Macs. And, I have the feeling that native OpenGL might solve some of the graphics problems anyhow. Chances are, I will be too busy to even implement this hairbrained scheme.

 

But, this is a bit off topic, right?

[Entropy]

Anyway, I started working at the arrow code on the server, and I would really like if someone is willing to work with me for the client side.

There will be a few new animations/frames, like extend the bow, let the bow go (unextend), fire, etc.

[Drakos7]

Ttlanhil just committed 3 of the patches I made a while ago, so that is some stuff for 1.5.0. I did not submit my quick8 spell bar for you, Entropy, because no one told me there was going to be a code freeze for this past version. The addition of the engineering skill also made it not fit right. I plan on working on that to get it nice and neat, and other HUD/interface ideas that have been in the recesses of my mind. One thought was to populate the video resolution list (or the pixel depth) from a SDL OpenGL call instead of having a fixed list. Nothing too stellar at this point though.

[Entropy]

Ok, well, no one is very enthusiastic to work with me at the arrow code, so let's try something much easier: The landmines.

Basically, all it needs is copy and paste the bags code, and replace the 3d object for the bags with something else (depending on the type of the mine, we'll have a different 3d object). Since we don't have 3d mine objects for now, we'll need to use something else for the tests, such as a sign or small rock or whatever (needs to take the space of a walk tile or less).

 

So, anyone willing to work with me at this?

[Torg]

Ok, well, no one is very enthusiastic to work with me at the arrow code, so let's try something much easier: The landmines.

<snip>

So, anyone willing to work with me at this?

I'm happy to work with you on both of these, but given my current availability I think I should start only with the land-mines.

 

I'm also not quite sure I can get my head around the logic of arrows efficiently enough (I'd waste too much time to be worth trying to code it). That said, if no-one else is interested, I'll give it a go after the land-mines.

[bluap]

I'm also not quite sure I can get my head around the logic of arrows efficiently enough (I'd waste too much time to be worth trying to code it)...

That's similar to why I didn't jump forward. I'd be happy to give the arrows a go if I knew a bit more about what's required. My main reservation is the actual drawing of the graphics, I've not done that kind of thing before. If the client already contains code that does similar stuff then I guess I can pick it up along the way. The actual flight of the arrow will require a bit of maths to make it look realistic. There's also the obstruction handling but I assume that is mostly server side. This all sounds like a challenge. Your call Entropy. If you don't mind working with a bit of a novice I'll do it.

[Entropy]

What the arrows 'candidate' needs is a very, very good understanding of Cal3D, bones, skeletal animation, and math..

So far, only Karen Rei and Xaphier meet those requirements, probably karen Rei more because she worked with the cal3d bones a lot during the eye candy thing..

 

Well, anyway, is there anyone else who wants to help with the mines? The client work can be distributed a little.

[ttlanhil]

I've got very little practice with working in the 3D part of the world (the new weather stuff is probably a large amount of my 3D work) but I should be able to do pretty well with networking and maths and the like (realistically, though, how much work would this be? add_3d_object_from_server with [object ID, 3d-object filename, x coord, y coord, z coord], remove_3d_object_from_server [object ID], add/remove items from the map data, and then potentially another send_special_effect call for explosions?)

ed: Oh, and load the needed 3d object/texture data from file, if needed

 

either way, I'd suggest splitting the landmines work into another thread so we can discuss stuff more (unless from now on it'll all be in PMs or ingame, anyway)

Edited June 12, 2007 by ttlanhil

[KarenRei]

Just an update: I've talked with Daniel, and I'm now working on adding in custom ambient, diffuse, and specular to each texture. That way we can have, for example, higher ambient on snow and lower ambient on dirt, make realistic metal surfaces, etc.

[Entropy]

Where will those values be stored? In the 3d object, or in some xml file that will store unique values for each texture?