PDA

View Full Version : legacy-2 release criteria


chippo
February 9th, 2007, 12:28 AM
I see (often) people inquiring into when legacy-2 will be released. For me, this is silly, 'cos they could SVN legacy-2, compile and play right now, if they weren't scared of a C++ compiler.

However, I'm not them and they want some arbitrary point in time to be stamped with legacy-2-release. My question is: "What are the criteria under which we'll decide that legacy-2 can get called legacy-2?"

Is there a list up somewhere? I personally feel that legacy-2 is pretty stable and solid, even right now. If it were up to me,I'd be happy to release legacy-2 when:
- The documentation has been updated enough for a newbie to actually compile the fucker from sources without asking any questions in the forums (this is my job).
- The opengl interpolater actually does the things the menu allows you to choose (they might be dithering methods). This is so that legacy-2 can look as good as legacy-1 (with appropriate choices).
- The something-or-other pruning is happening (which will make legacy-2 faster than legacy-1, 'cos right now it's the other way around).

Cheers,
chipenthog

smite-meister
February 9th, 2007, 04:23 AM
Here are the things I think should be done before a 2.0 beta release:
- JPEG texture support (I'm on it, easy) done
- Tweaking the DECORATE class system a bit (me) done
- Flawless handling of 3D floors and software translucency in OpenGL (Pate is working on this presently)
- Proper BSP-based frustum culling in OpenGL (Pate again)
- PK3/ZIP data files (a bit more tricky) done
- Fixing the ACBot code so that it won't hog the entire CPU in large maps
- Porting all FS additions made to Legacy-1 after the branching to Legacy-2
- Updating documentation, in-game menus and console commands/vars
+ maybe a few surprises :D

Before the actual release, we should also have
- Working netcode
- Lots of valgrinding done, no more memory leaks
- Integrated BLOCKMAP builder (to make huge maps such as Deus Vult work) done
- Sprite and MD3 skins working (again)

smite-meister
February 17th, 2007, 04:40 PM
Seems I can't edit my own posts... *confused*
Anyway, JPEGs, the DECORATE stuff and ZIP/PK3 files are done now, just the renderer, bots and FS to go :)

MR_ROCKET
February 17th, 2007, 11:52 PM
drool..;)
Let me rephrase, DROOOL !..

PumpkinSmasher
February 18th, 2007, 01:10 AM
Seems I can't edit my own posts... *confused*

After about 2 says it no longer lets you edit your post.

But all that sounds good, i can see the progress in legacy 2. So are yall using a renderer from pate or hurdler? either way legacy 2 will be the shit. Can't wait for this project to see an official release, or even reach beta stage. I don't question that it will get released, but it does seem to be taking quite some time. But I understand the difficulty in such a project, and I appreciate the work yall have contributed to doom legacy.

Hurdler
February 19th, 2007, 06:38 AM
It will use pate's one. I haven't touched the code for a while. I wish I can find someday the time to help a bit.

DooMAD
February 19th, 2007, 09:45 AM
I see (often) people inquiring into when legacy-2 will be released. For me, this is silly, 'cos they could SVN legacy-2, compile and play right now, if they weren't scared of a C++ compiler.
And even if they don't know how to use one (myself included, heh), there's a small archive of unofficial alpha builds accumulating on the development page (http://legacywiki.net/index.php/Development) of the Legacy Wiki, including a shiny new one compiled today (thanks Exl). I know a few people are eager to check out this latest one.

MR_ROCKET
February 19th, 2007, 10:57 AM
Thank you Exl ! and everyone else for that matter.
Here's (http://home.comcast.net/~mrrocket/temp2/overlay3.wad) how those hud overlays are looking so far.
Right click and save, run in opengl for now.
In video options change screen size and scale status bar.

Danimetal
February 19th, 2007, 11:22 AM
The more I read the code the more puzzled I am at it... I guess one has to be experienced enough to work with this code and I´m not that.

MR_ROCKET
February 19th, 2007, 01:57 PM
Holy cow this is freaking amazing guys!
I'm finally getting to see what you've been doing the last few months Smite. ;)
I'm working with that wad I started on a while back, with the HFX hires textures, well now NTEXTURE and transparency is rock'n in opengl, this is sweet. 1600x1300 smooth as 600x400! They are still png's right now, I'll test them out as jpeg's soon though.
Drool drool drool

Now how do I go about pack'n this sucker up so legacy2 will run it as a zip? :D - or a least a briefing on the internal directory structure setup for one pk3/zip. eg. pwad in a maps folder, other lumps in a lumps folder, textures in a textures folder, etc.
And man I wish there was a way to speed up glvis, but at least the map can be tested with glbsp in software mode until I'm ready to run in opengl. ;)

Pate we need colormaps!
Hurdler we need coronas!*wacky*

smite-meister
February 20th, 2007, 05:35 AM
They are still png's right now, I'll test them out as jpeg's soon though.
Better keep them in PNG format. Remember that JPEG images have no alpha channels.
A good rule of the thumb is that if you've drawn the texture by hand, or it has transparency effects, you should save it as PNG.
If it's based on a scanned image or a digital photo, it may work better as JPEG.

Now how do I go about pack'n this sucker up so legacy2 will run it as a zip? :D
ZIP/PK3 archives have three main advantages against WADs:
A1) Compression. They are generally smaller in size.
A2) Long lumpnames, directory-like structures (I'm still referring to the compressed files inside the ZIP as lumps, because they are conceptually the same thing :))
A3) You don't need WAD editing tools to make them, any ZIP program will do.

Disadvantages:
D1) Slight performance penalty due to having to decompress the lumps when they are used.

Now, if you only want to do a texture package with PNG and JPEG textures, a WAD file is generally a better choice than a ZIP file because the texture files already are compressed, so the extra ZIP compression/decompression round only causes a performance penalty.

However, if you can force your zipping program just to "store" the PNG/JPEG texture files in the ZIP file without compressing ("deflating") them, it would be perfect.
You get A2 and A3 without any disadvantage.
(In the UNIX commandline zip tool you do this with the -n switch.)

MR_ROCKET
February 20th, 2007, 09:06 AM
Yeah I remember you saying jpeg's don't have the alpha channel. I was mainly going to test them out. And md3's I haven't had a turn at that stuff yet in L2.

Anyways about the zip/pk3's. Well the textures are in the wad but I'll keep that in mind about the load times maybe with something else that may have to go external sometime.
But a directory structure example for this would be nice. :D eg
.wad,.~gw/MAPS/LUMPS or just /LUMPS
.png,.jpeg/TEXTURES
.png/TEXTURES/SPRITES
.wav,.ogg/SOUNDS/MUSIC
.md3/MODELS
.acs,.fs/SCRIPTS or just /LUMPS

Usually pk3's are packed up something like this, I'm thinking the above is how it would be done for a wad file and it's resources, what method does L2 use?


Actually I was more so thinking of the .gwa and .~gw though, or at least ~gw. I mean sure they could be extracted with the pwad to the legacy directory, but that sort of restricts it a bit you know.
Hmm, can a ~gw be loaded as an internal lump in a pwad in XWE, and would it possibly work? hmm - I havn't tried this yet heh. If so, then disregard pk3'n them :D
Edit: nope, at least not as BSP lump type 43.

If the wad and it's glbsp and vis builds are 3 separate files and could all just be read from a zip/pk3 that would be sweet also. Currently glvis is so slow that it's almost something that should be done as a final thing before release of the wad and packaged with it, it seems. Something like what you would do with a quake3 map before release. - run a build, pk3 it and playtest.
Anyways, how should I pack it up with the gl output files?
Do they need to be put in a GL folder or something?

- If they could be zip/pk3'd with the wad, then wouldn't the pk3 be able to be read from any location that way?
Which would make things easier for the end-user, not having to run a build on the wad and just load the pk3 and all it's contents form anywhere. I can understand if legacy runs glbsp at load up, but glvis would take much longer.

Also would it do no harm in including glvis .~gw outputs for all the iwads that L2 runs? and include them with Legacy2.

Pate
February 25th, 2007, 06:49 PM
Holy cow this is freaking amazing guys!
Pate we need colormaps!


Just so you know, I'm currently visiting Melbourne for six months or so. I don't have proper Internet connection (at least not at the moment) so updating the GL renderer will most likely be slow.

Green_Ogre
February 25th, 2007, 07:17 PM
Too bad you only have limited MD2 support. It would be nice if you could use the entire jdrp model pack along with the jdep texture pack.

MR_ROCKET
February 25th, 2007, 09:40 PM
Roger that Pate, I'm dreadfully sick right now and have a flight booked to Florida in a week..argh
Though I'll only be gone for about a month.. See you in 6 months man *wave*

Too bad you only have limited MD2 support. It would be nice if you could use the entire jdrp model pack along with the jdep texture pack.
( Limited MD2 ) support is in ( Legacy 1.4x).
( Legacy 2.0 ) supports ( MD3 ) models..