Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: WMCoolmon on February 26, 2005, 07:16:27 pm
-
- Support for more than two primaries
- Secret feature is accessible via F3 in the main hall, and new to this build, ~ and backspace in-mission using a debug build. (NOTE: You can easily make FS2 crash if you use it in-mission since it bypasses the usual validity checks done during parsing)
- Bumped MAX_ROTATING_SUBMODELS to 50(!)
- A couple bugfixes
The complete list of changes can now be found in a TXT file in the ZIP, named the same as the ZIP.
http://fs2source.warpcore.org/exes/latest/C20050226.zip
Exposition on the secret feature:
Essentially, the secret feature is a GUI system completely separate from the main/original Freespace 2 one. Rather than attempt to work from predetermined art templates for the room, it functions much more like the Win32 or any other operating system's API. Not only that, but it also supports windows.
Currently, there are only a few classes of items that are implemented - "Text", "Button", "Checkbox", "Tree", and "Window". They're all pretty basic right now, but of course it's possible to replace them with any graphical display file format that Freespace2 supports...as well as further expand the controls to do more. Today I spent about four hours updating the system so that it would handle keypresses and 'active' objects, although there isn't actually a control that receives keypresses...yet. :p
What this means for people who don't give a damn about the specifics (:p) is that it's possible to implement a GUI that automatically substitutes in images if they're supplied, or default to the current behavior of using the standard 2D shape and text functions.
What you can actually do now is get a fullscreen view of any LOD for any ship class, play around with the ship flags for that class of ship, toggle the model rendering flags that seem to do something, and read the description...in-mission. Note that the model rendering flags don't actually change how ships look in-mission, just the fullscreen preview, but they are fun to play with anyway.
Edit- Sample screenie:
(http://fs2source.warpcore.org/wmcscreenies/labscreenie.jpg) (http://fs2source.warpcore.org/wmcscreenies/labscreenie.png)
Added to the website.//redmenace
-
*presses F3 in the main hall*
Options ->Wireframe crashes to desktop, but all in all, not bad at all. ;)
-
Looks good. Don't know if allowing the player to toggle ships flags in-game is such a good idea though. I'd imagine we're going to get quite a few crashes from people playing about with that feature :D
-
The in-mission stuff only works with a debug build, actually.
-
*wonders if it can apply to weapons models too* *wants to disable the no dumbfire on helios*
-
Will alt-tabbing break your computer?
-
Mmm, whered you get that Perseus?
-
I still get
(http://www.geocities.com/solatar6189/screen01.JPG)
on all fighters in the player's squadron.
EDIT: And crashes when anything warps in.
It seems that the newer the build, the more bugs it has in it for me.
-
You got yerself an opengl problem. Switch to D3D asap. If you already are, I am clueless.
-
the overflare problem with nebs is still there.
*goes off to test the other builds in the other thread
-
afaik if you run OGL you need updated drivers. Other people I have seen use OGL with 4.4 or equiv get what you got.
-
Alt-tabbing:
If you do it in D3D mode, it will crash FS.
White boxes:
Meh. :p Sorry if you said this in the other thread already, but is it D3D or OGL or both?
Background probs:
Thanks, Singh. If you can figure out where they started, that'll be pretty helpful. :)
Interface status:
I added a system to define images for skinning. It could easily be expanded to support models as well. My question - is there anyone _seriously_ interested in skinning the FS2 interface? If so, how would they like to do it? My current thinking about the general system is that there'd be an interface.tbl, with different sections for the various screens. If one of those sections is found, then the original screen isn't displayed, and the new interface system is used instead.
-
dont suppose we could get *cough* on the fly table editing? would make fine tuning things alot faster.
as for skinning the fs2 interface, how many files are we talking about? i could easily make buttons from scratch that look very similar to the originals. all id have to do is come up with a layer style in photoshop and apply it to very simple 2d shapes. it could take anywhere between 30 seconds and 3 minutes a button. id assume that the variety of buttons isnt very big, and im not really willing to do hundreds or thousands of files but if you produce a lits of stuff you need il take a look at it.
-
[Morpheus]When the text input control is ready, you won't need to[/Morpheus]
Edit: Well, my thinking is that any 'new' interface wouldn't be exactly like the original FS2 one, or one mod would be making artwork but the system itself would be easily configurable with other artwork.
What I'm looking for are standardized images to go with control types...for example, checkbox states, or window captions. It'd be nice to keep the Freespacey feel for the initial batch, but it's not necessary. However, the stuff would have to be resizable and efficient. I'd like to use as few images as possible for the base types so that we don't have the hellish numbers of images that there are now.
-
Originally posted by WMCoolmon
My question - is there anyone _seriously_ interested in skinning the FS2 interface?
Lemme put it this way - I'm interested in joining other people in working on a new FS interface, but if I'm the only one, I don't think I'd be able to handle it.
-
put it that way i could do the buttons, perhaps somone else could do the backdrops.
-
This is what I'm thinking would be nice for a Neo-Freespace skinned dialog/window (attached). Uhm, a little more artsy too. ;)
I'm sort of thinking that this would be a good chance to get away from the possible legal problems with distributing the FS art. Done right, we could also use *one* set of art, or at least a lot of it, no matter what the interface was. And make it easier for mods to whip up their own artwork.
A lot of the work will, undoubtedly, be coding it in for the various sections. :sigh:
Edit: Oh, for windows I was thinking of having the following images:
Caption background
Hide button (inactive/active/pressed)
Close button (inactive/active/pressed)
Main body (excluding borders) - different dialog sizes would be a problem.
Left/right/top/bottom borders for the body - these would extend all the way, so either the left/right borders or the top/bottom borders would have to cut off or diagonalize their edges. The chief problem is handling multiple-sized dialogs; I haven't come up with a good way to do that not involving large amounts of images. I should be able to rotate images 90 degrees without much trouble.
For resizing purposes, it would be possible to force windows to the nearest multiple of 32 or something; I don't plan on implementing user-resizable ones, as that would be a bit messy.
-
or...
(http://server2.uploadit.org/files/nukebomb-thing.jpg)
-
I like. :)
Can you break it up into sections?
-
im not too sure that backdrop would scale easily. if i were to eliminate it i could cut the window up easily. would there be a way to fil certain parts of the image with a tile pattern, solid green for example, then i could create a tile for the background, and then devide the frame up. the buttons and titlebox would be fixed size.
-
Tiling is possible, although it'll take a little more work. Alpha blending is also possible, I think, depending on the file format used.
-
i figure youd have to have 4 fixed sise points at the corners, plus 4 scalible sections that may be stretched or tiled
heres an example
(http://server3.uploadit.org/files/nukebomb-example.jpg)
areas in green will be fixed size images, areas in red will need to either tile or stretch. theres not much variation in them so it shouldnt even be noticable. this way windows may be scalable. this is about the minimum window size.
-
I think Nuke has found a good way of doing the windows. You can even make the right/left borders mirrored, and the top/bottom ones angled 90 degrees, so you can do all the red bits with 1 image file.
Nuke, couldn't you make the top left green bit consist of 2 green bits and a red one? That way you can have the text in there as long or short as nessecary, and still only need 1 image for all windows.
-
Hmm, it'd be nice if the close/hide buttons were separate. That way the clickable area could automatically be calculated and, of course, the buttons can have individual highlight images.
How about this -
Upper right window border/upper left window border/upper middle border
Caption text background image - Goes on top of the above
Hide button
Close button
Left/right borders
Lower right window border/lower left window border/lower middle border
That's 11 images, 15 if you count the state images for the hide/close buttons. (I assume in hidden state, the bottom three images will just butt up under the caption and the left/right borders disappear entirely)
Edit: The only problem with using one border image for all the mid ones is if somebody wants to do an extruded border - in which case they'd have to be rotated the opposite direction to look right, and at least two images would be needed to simulate lighting. OTOH, I might be able to add a 'rotation' parameter so you could specify something like what you're saying.
How are you thinking of doing the background, Nuke?
-
WMC: I'd say unless otherwise specified in the table, only one border file is used, rotated so the inside stays in. I really do think the top border could be using the same file as the lower and sides ones. If you do the caption modular, you won't need more then one image set for all windows.
This'll give you:
Border = 1 to 4 files
Lower corners = 1 to 2 files
Caption = 1 to 3 files (3 for modular, 1 for single. 1 would mean a seperate one for each windows)
Top right corner = 1 file
Buttons = 2 to 6 (6 counting states)
Total:
6 to 12, or 10 to 16, counting states.
If you add one tile for the background, this'll give you 7 images to a window, if you go minimum and don't do anything special for the states.
-
well no, that would need to be a fixed size, else the tiling would be screwed. you could have a small and large titlebox kinda redundant but its better than the current system. as for mirroring, im not sure that would work either. because the image uses a bevel effect it would make visible lines at the joints. it could be done but it would only make the design time longer.
each element could have a base image titlebox.tga. this image could have siblings for different states, such as titlebox-inactive. for buttons you would have button-mouseover or button-clicked. you would also need masks to define hotspot's masks would work on a per image basis (baseimage-mask) any item with a mask is assumed to be a button. buttns need 3 states, normal, mouseover, and clicked. borders need only one image, buttons need like 4. alpha chanel will define the transparent parts of texture, and also would be used for alpha blending. id like to be able to assign different shades to different tiles via table (ex: $tile: 0'0'255 image.tga), any pixels that uses that color would be substituted for the tile.
-
Nuke: Why can't you do the title box more or less the same way you did the whole image? Just make a monomere (if you remember your organic chem you'll get my drift), and two borders to terminate? You wouldn't be able to do very small steps, but if you make the monomere 10 pixels wide, you should be fine.
The less images required, the better. The more images possible, the better. Just make sure you don't NEED more then a dozen images for a window. Just to make the step to skinning easier.
-
i could if you want a drab monotone titlebox :D
im thinking 17 files
2 for title box (active/inactive state, optional)
4 side borders
2 corners
2 buttons*3 states+mask
1 center maybey
-
Well, as I said, the less files needed, the better. If you make a proper interface table, you could get aaway with using 10 files for ALL windows. If you allow somehow to replace all pixels of one colour with another colour, you could do state images even easier.
This would allow for a lot of skins to be made quickly and easily, making it less of a disaster to replace the entire interface. Which is good.
-
of course i assume this is the standard window. any window in the game will use the same 17 files. if you want a larger window you could substitute the title bar for a larger one. splitting it up into 3 wouldnt be any worse than making 3 different sizes. also i could make the buttons scalable as well, so that you may put more than 2 there. id like the middle to be tile filled.
-
Any of the images can be scaled along one axis to fit. So if you had a big long title bar, it could be squished to form whatever size needed. That might not look so hot though.
Another thing: No hotspots, at least not right now. They might be nice to have, but it's too much work to be worth it for now. They also aren't really necessary IMHO, they'd just make things harder to press.
And a final note before I'm off to bed - some of the windows will be nonmoveable, or nonhideable, or noncloseable. For the latter two, I figure I'd just remove the appropriate button(s).
I doubt I'll be doing any pixel color replacement, that'd require a more fine knowledge of the texture system than I have atm and would discourage things like shadowing and such on buttons. If the skinner really does just need to replace one color, they can take the extra 10 seconds to pick a new color and use the fill tool in paint. :p
Text colors will be settable though.
-
still crashes for me, like it did before, and it crashes such that i cant copy and paste the info, it just leaves that screen up there, frozen
fix please!
-
while this is the current build thead il say it again here, im having problems getting the $tech model: feature to work, i can either get the model to display too big or not at all. infact all 3d icons generated for my stuff are zoomed to close, cutting out most of the ship/weapon. my best bet is that it has a problems with pcs created models. i tried every trick in my big fat book of tricks and nothing worked.
as for the ui, i could probibly come up with a way to scale the title bar and implement new buttons, but it will require adding images for the upper corners, however buttons and titlebar will be optional. also witout the tile fill feature the center image will need to be scaled to fit. also the lack of hotspots will require me to redo the buttons a little so they dont have a rediculously large trigger area. the new style im thinking about would allow extra buttons to be placed anywhere around the border with a minumum of added artwork i think rather than a tile filled window i think using alpha would look cool as well. anyway it would require 8 border images plus images for buttons, titlebar, and any other extra buttons or features (status bar for example) you may want. it will also allow you to have different titlebar, button styles while maintaining a 3d shading. also come up with a list of different free floating button styles you want, radio buttons scollbars and such. ill attach an example of the new system as soon as i produce one.
(http://server3.uploadit.org/files/nukebomb-ex2.jpg)
ok, this system uses 4 corner images and four border images. note that in dark red you see the same image used twice, on either side of the optional status bar. this is to ilustrate that this way you can really add buttons or other features on pretty much any of the 4 borders while using a minimum of textures. the buttons may be arranged in any order, in any number or not at all. the titlebar may now scale and it souldnt look too abnormal with the metal texture. this is just an example, the final version will be as space effietient as possible.
-
I can't seem to get the secret feature to work. Pressing F3 in the main hall does absolutely nothing. Do I have to activate some tags or alter some tables to get it working ?
I am using OpenGL, I tried D3D too but it does nothing special either.
And there's more, just tried the triple primaries, third primary cannon is not working either, Do I have to "doctor" table files to get it right ?
BTW I can see the third cannon on the weapon loadout screen and on the HUD display, but it does not fire. I can only hear this "gun is empty" sound.
I know FRED2 is little outdated and LITTLE broken at the moment, but is it supposed to detect three or more primaries mounted on fighters ?
-
you have to be in the main hall for it to work. in game (~+backspace), it only works with the debug build. also make sure you are running the right build, all too often i download it, extract it, and forget to select it in the launcher, and run the game. the resul is i can never get the new features to work :D
-
OK. Problem solved, thanks a lot !. I thought main hall was the main screen of the whole game (the one where options, barracks and ready room are located.)
Still problem number two remains, Somehow I can't fire with more than tho primaries.
-
yea some table editing is required, you could probibly just hack a mission to let you fly a shivan fighter.
-
Nuke: That looks good, but in theory, all of the dark and light red bits could use one and the same file, and the blue corners too, right? The caption and status bar could even be the same file(s), by the looks of it.
Now, don't get me wrong, I'm not saying they should be seperate files, but that if a mod would want to do interface art quickly, they could be the same image. This'll leave you with 4 files, assuming you make the end of the caption/status bars the same image mirrored, and all the sides/corners are rotated to fit. You then only add the images for the buttons, which can go from 1 to 9, according to state and amount needed.
These requirements sound very nice, because it'll allow mods to be reallly quick with the skinning. Now, if you make a table to allow for seperate images for each of the regions as well, you'd get a best of both worlds situation, allowing one to make each image special, for a maximum of 20 files.
-
Just checked the secret feature, very neat indeed ! But then my o'l reliable decided to freeze completely, so I had to restart.
Any idea when this secret feature decides to show up in non-debug build, it's just because the missions are not working in debug so I have to cut back to windows and switch build if I like to watch the secret feature. (Gosh, is there any official name for it ?)
Oh yeaf, the afromentioned freeze happened at SF window.
-
Sorry to intrude on the ub3r interface conversation. :p
Originally posted by WMCoolmon
White boxes:
Meh. :p Sorry if you said this in the other thread already, but is it D3D or OGL or both?
It only occurs in D3D. My game basically looks like crap in OGL though, and I really don't wanna go through that.
-
I have ATI 9600 XT, that's why I begun to prefer OGL.
-
I've got an ATI Radeon 9000 Pro, but for some reason D3D still looks better.
-
Nice coincidence, I wonder if drivers have something to do with it.
Though I'm just not updating my drivers as often as I should.
-
Originally posted by starfox
I have ATI 9600 XT, that's why I begun to prefer OGL.
Eh? I've a 9600Xt and I prefer D3D...
Originally posted by starfox
Though I'm just not updating my drivers as often as I should.
Err. You shouldn't be updating your drivers unless you're having issues with the current ones.
ATi doesn't recommend you DL every latest driver.
-
Originally posted by kasperl
Nuke: That looks good, but in theory, all of the dark and light red bits could use one and the same file, and the blue corners too, right? The caption and status bar could even be the same file(s), by the looks of it.
Now, don't get me wrong, I'm not saying they should be seperate files, but that if a mod would want to do interface art quickly, they could be the same image. This'll leave you with 4 files, assuming you make the end of the caption/status bars the same image mirrored, and all the sides/corners are rotated to fit. You then only add the images for the buttons, which can go from 1 to 9, according to state and amount needed.
These requirements sound very nice, because it'll allow mods to be reallly quick with the skinning. Now, if you make a table to allow for seperate images for each of the regions as well, you'd get a best of both worlds situation, allowing one to make each image special, for a maximum of 20 files.
it may very well prove to be easyer to work with more files, than go through the trouble of getting the lighting just right so that its seamless. theese examples dont take me much time at all to make, and the time it would take to crop the individual sections to files isnt that much of a hassel either. also from a coding standpoint it would be easyer to use more images than it would to implement a few pixel math functions. oviously [V] used this philosophy to excess :D
this way you can render the thing much as i have done, and then break it up. it would take me more time to worry about having to get the lighting right when things get mirrored, than it would to crop the parts. this alows wysiwyg interface art development rather than trying to figure out what its gonna like like when it gets in the game. and for the left brained modder, i think thats the better way to go. mind you the 8 border images will have other uses than just windows, i figure frames and scroll boxes will use them as well. it will be very effietent.
the alternative is a flat look which is worse than the windows interface, and you know were better than microsoft :D
my goal is to make a versitlile system that is as astheticly pleasing as it is effietient. also the reason i agreed to to this is that its something i can create quickly so that it wont take much time away from my other works. if i thought id be creating a thousand files i wouldnt have agreed to it. i personally thnk the modders will like it.
-
I don't know, perhaps the only reason I've used OGL some much is the well-known Shinemap issue.
-
hey i got bank 3 to work, yay! and i thought the chaos had too many guns as it is :D
-
I've a little question:
I'm running Linux AND Windows. In Linux I sync with the CVS-Tree and then I compile the source.
Now: Where should I post errors, little things etc. that doesn't belong to any build?
For example:
In Linux I can't use the throttle- and rudder-axis of my Joystick (but those are working fine under Linux and are recognized by the options-screen of the game
).
If I should post such things in MANTIS: I've tried to create an account, but MANTIS won't send me a password...
Tanks for your help!
-
Woo-hoo ! I just got the Bank three working on the SB Seraphim !
Thanks a lot again for your support fire.
-
It's a nice build.. but i find a few problems:
In almost every Mission i have a frozen screen after 3:58 Missiontime (tested with Sync, Revenge and Aeos Affair), when i have this screen i can only quit this Game with CTRL + ALT + Delete.
Although i have a few graphic bug with Ships on a long distance.. i see many long grey dashes.
-
It freezes for me too. No error message, nothing, just a sound loop.
my flags are: -spec -glow -pcx32 -jpgtga -d3dmipmap -nomotiondebris -2d_poof -pcx2dds -d3d_no_vsync -dualscanlines -ship_choice_3d -targetinfo -orbradar -3dwarp -ballistic_gauge -smart_shields -snd_preload -fps -ambient_factor 80
-
Me too, all features on, -ambient_factor 75
-
Originally posted by Mr_Maniac
I've a little question:
I'm running Linux AND Windows. In Linux I sync with the CVS-Tree and then I compile the source.
Now: Where should I post errors, little things etc. that doesn't belong to any build?
For example:
In Linux I can't use the throttle- and rudder-axis of my Joystick (but those are working fine under Linux and are recognized by the options-screen of the game
).
If I should post such things in MANTIS: I've tried to create an account, but MANTIS won't send me a password...
Tanks for your help!
E-mail Inqui about the problems with Mantis, and there's a FS2_Open Linux thread in the main SCP forum that you should be able to post bugs in.
Originally posted by Deepstar
It's a nice build.. but i find a few problems:
In almost every Mission i have a frozen screen after 3:58 Missiontime (tested with Sync, Revenge and Aeos Affair), when i have this screen i can only quit this Game with CTRL + ALT + Delete.
Although i have a few graphic bug with Ships on a long distance.. i see many long grey dashes.
That's very interesting...and it sounds about right. The freezing in the middle of the game bug seems to have something to do with DirectSound, and started around the time of the Linux merge...I haven't touched those files in awhile. I tried to debug it several times, but the loop it's stuck in is apparently somewhere deep inside the DirectSound DLLs.
It doesn't seem to occur if you use -nomusic.
Originally posted by Solatar
It only occurs in D3D. My game basically looks like crap in OGL though, and I really don't wanna go through that.
That it's in D3D is interesting, and narrows down where it must be occuring. Although it means I'll be less able to solve the bug. :p
Interface stuff
I've got most of the code for window skinning in; I still need to fixx0r the client positions without skins though. Mostly I need the art to test it :p
Here's what interface.tbl should look like:
#Lab ;;Referring to the 'special feature' room here
$Window
+Caption:
+Mouseover:
+Body:
+Hider:
+Mouseover:
+Clicked:
+Closer:
+Mouseover:
+Clicked:
+Border
+Top Left:
+Top Left:
+Top Right:
+Mid Left:
+Mid Right:
+Bottom Left:
+Bottom Mid:
+Bottom Right:
#End
-
hey are you going to write an interface editor for this also?
(sorry if you said so, I just saw the table def and haven't read anything else in the thread)
-
Originally posted by WMCoolmon
The freezing in the middle of the game bug seems to have something to do with DirectSound, and started around the time of the Linux merge...I haven't touched those files in awhile.
Update to current CVS and try it again. I missed a single friggin line in the merge. It was using the wrong set of macros and would probably cause a race condition inside DirectSound.
-
Don't forget scrollbars. That's something the current system seems to lack, and it's actually really noticable on the shiplist. At the very least, consider it when making interface. I like the interface though, at least in principle; it's extremely functional and there's no issue with things not working when they should. Except that LOD0 and LOD1 are loading the same thing and the other two LODs are 1 and 2 instead of 2 and 3. But that probably has nothing to do with the changes.
-
I'm not sure what's up with the LODs. The relevant code is pretty simple, I've gone over it twice, but it seems to be related to the way FS stores LODs or something.
for(int i = 0; i < Num_ship_types; i++)
{
ctip = cmp->AddItem(NULL, Ship_info[i].name, (void*)i, false);
for(j = 0; j < Ship_info[i].num_detail_levels; j++)
{
//Number->String
itoa(j, buf, 10);
caption = "LOD ";
caption += buf;
//Now that we have the string, add it to the current ship
cmp->AddItem(ctip, caption, (void*)j, false, change_lod);
}
}
-
Originally posted by taylor
Update to current CVS and try it again. I missed a single friggin line in the merge. It was using the wrong set of macros and would probably cause a race condition inside DirectSound.
When/where did you make the update?
-
A few minutes before that post. The log should have been sent to the dev-list if you are subscribed. Only code/sound/audiostr.cpp was changed and the CVS log is "uugh, missed the initial tree move (WMC: probable locking problem)" so you can make sure you got the update. :)
-
Ok, this build causes my effects graphics (in most cases) to become white bricks. Ugleee.
-
im gonna do some gfx for you. im gonna alpha the outer edge to zero and leave the inner edge opaque for now. also you need a way to fill the center with a solid color. im gonna use a 512*256 base resolution and cut it up from there.
-
???
The effects I use work perfectly in all other builds.
-
ok, the interface files are at www.game-warden.com/nukemod-cos/fsinterface/interface.zip
also i can easily add cancel and apply buttons for dialog boxes, just let me know what you need as you need it.
-
Thanks nuke. :D
Coming soon... (pending bugfixing of unresolved issues)
(http://fs2source.warpcore.org/wmcscreenies/coming.jpg) (http://fs2source.warpcore.org/wmcscreenies/coming.png)
-
is that an on the fly pof editor?
:D
wait thats table data, this could be cool, freespace would be all you need to make mods.
-
Not quite. :p
-
there is the little problem of FS not haveing a save_pof_file function, and it would probly be prety harry to make one.
-
would allow for some wysiwyg editing. would really be usefull for glowpointing. onothier thing i can think of, use it as a viewer for shine/glow/env map editing. you need a reload textures button though.
-
it would be great, you'd never have to worry about your editor being out of date or anything, but it would be a major pain in the ass like you wouldn't beleive.
-
im still curious to see my interface graphics in actions.
-
Hmm, gr_bitmap is very slow...
FS may be able to render a fully-textured 50k polygon ship, but tile the same 28x4 image 25 times and it dies.
Edit: You're gonna have to wait til tomorrow, Nuke, my quick-and-easy solution didn't work out so well. :p
Just a note, the set seemed to be missing the top right and mid right images, it looked like they got overwritten by the caption image.
-
/*looks at gr_bitmap*/
-
i shought you said theyd be stretched, not tiled. so i only made the texture 4 pixels wide. how wide do those need to be? that also means i can give them a little bit more textured look.
-
what you need to do is get a little lower level than gr_bitmap, you might need to make a vertex buffer, that would defenately be faster than the way your doing it,but maybe I should make an interface for complex on the fly geometry, and give it some utility functions whle I'm at it.
if you can't get it wirking by the time I commit my code base I'll get that done for you, other things have needed this for a while anyway.
-
grrrr stupid photoshop. ill add the missing files to the zip and make the borders abit wider.
also bob will be happy to know that freespace alt-tabbing works quite well, i can get out open 20 images ain photoshop and i can still go back and fire my minigun :D
-
Stupid timewarp...
Originally I was going to stretch them because it should be quicker than multiple calls to gr_bitmap, I just wanted to see them in action and tiled them. However, gr_bitmap was so damn slow that my computer was getting 5-10 seconds per frame.
At the moment, the width of the borders should be the same as the width of the corners, and same thing for the height.
-
I find myself just alt-tabing for no reason, other than just becase I can. :D
-
Interesting, But, i 'm wondering if we could have the Perseus Cockpit with just the Last Shinemaps/Glowmaps without having the cockpit files ?
-
Originally posted by Bobboau
what you need to do is get a little lower level than gr_bitmap, you might need to make a vertex buffer, that would defenately be faster than the way your doing it,but maybe I should make an interface for complex on the fly geometry, and give it some utility functions whle I'm at it.
if you can't get it wirking by the time I commit my code base I'll get that done for you, other things have needed this for a while anyway.
You know, what I was thinking of suggesting for Ferrium was making a class for simple objects, which would store all the info needed to draw it. Then you could do something like:
bitmap *bmp_ptr;
bitmap bmp
void room_init()
{
bmp_ptr = new bitmap(id, xloc, yloc);
//or - more flexible but takes up more mem
bmp.init(id, xloc, yloc);
}
void room_frame()
{
bmp_ptr->draw();
}
What would happen is when the bitmap was either inited or created, all the stuff related do drawing that bitmap in the current location (the 3D data, vertex buffers, what-have-you) would be stored in the class. When draw() is called, the information is simply sent off to the video card. For stationary objects with a stationary eyepoint (read: interface), that would give a nice speed increase, while keeping all the variables in a nice tidy package.
Anyway, I think I'll be able to make myself at least a stretch function.
-
Originally posted by MetalDestroyer
Interesting, But, i 'm wondering if we could have the Perseus Cockpit with just the Last Shinemaps/Glowmaps without having the cockpit files ?
Er, do you mean the cockpit warning that comes up in debug mode?
-
well the thing is if you want the game to render anything in a fasion that resembles quick you need to pack as many pollies into a draw comand as posable, what the gr_screen function does is makes one four sided polygon, wich later gets turned into two triangles, what I need to do is add an option for drawing triangle lists (and point lists for that matter, that'd make the particle system slightly less painfull) and make a member function to the poly_list class for adding 2d elements to it, though it realy shouldn't be too hard, if it wasn't 4 am and I was going to wake up in two hours to go to school tomarwo I'd do it right now.
-
Originally posted by WMCoolmon
Er, do you mean the cockpit warning that comes up in debug mode?
Yes. And Did it appears into ingame mission too ??
-
ok graphics are fixed. i made the edge s 28 pixels wide, though that might not be enough.
btw freespace is still running in the background :D
-
:D
-
Hum, could you add into this new feature, a scrollbar for the ships list ? because I can see all the ships.
And i found 1 silly bug, when i want see the Colossus, my 3D card crashed, I mean, VPU recover from my ATI card reinitialized my 3D card because of an unknown graphic problem.
-
Whoot, glowpoints are coming!
-
On an unrelated note, is there a reason I can't play nebula missions anymore?
-
Okay, new build.
http://fs2source.warpcore.org/exes/latest/C20050301.zip
This build is provided as-is. It has:
- Changes to the turret AI code to make it speedier when enemies aren't present
- Changes to the techroom, these probably won't help with the crashing, but did remove some unneeded function calls. I''ve not been able to figure out what's causing it to crash; if I could reproduce it, it'd probably be immediately evident what the problem is and how to fix it, but I can't (not running with retail FS2 data anyway)
- The edit-ship-specs ingame thingy. Some stuff doesn't do anything. The controls will try to enforce values that don't crash. Note that stuff is saved when you press enter in the box; if the value changes, it means the one you entered was bad. Also, the cursor is always considered at the end of the entry box.
- The freezing bug mid-mission should be fixed, thanks to taylor.
-
Oh.. a new build? I will check it ;)
EDIT: I still have freezes.. now after 2:38 Minutes in 2 different Missions.
But i haven't tested it without Music.. i use following Commands:
-spec -glow -jpgtga -d3dmipmap -2d_poof -rlm -nobeampierce -dualscanlines -targetinfo -3dwarp -ballistic_gauge -smart_shields
-
Originally posted by Deepstar
I still have freezes.. now after 2:38 Minutes in 2 different Missions.
I've still got a few more related changes to make but if -nomusic had worked before then this one change should fix it. How bad it gets appears to depend on what system and dlls you have though so that one fix may not be enough for everyone. I tried making the fix game wide but then it was hanging constantly, on load, on exit, techroom, etc. I'm testing the newer, more specific fixes now and if I can't get it to hang then I'll add everything to CVS.
Oh and I did cause this by the way so no praise from anyone for fixing it. :rolleyes:
-
*praises taylor for fixing something else*
Seriously, how many bugs have you fixed, total? :p
-
Freespace 2 just keeps getting better and better :)
-
Originally posted by Goober5000
Seriously, how many bugs have you fixed, total? :p
Uhh, never kept track. Assuming that you actually want to know: mantis stats show 43 resolved at the moment, but between the Linux specific stuff and things that aren't in mantis... 4, maybe 5 times that many as a rough guess. I'm counting a few icculus.org fixes that I brought over too so that many over about 3 years isn't really that many in the end.
-
holy ****.
That's even more bugs than I've made. (I hope :nervous: )
-
ha! it's no were near as many bug as I've made!
-
This build locks up on me at 2 seconds mission time... in 2 attempts. Sorry WMCoolmon, but until a new build comes out where NO-ONE complains about a lockup, I'm gonna stick with PhReAk's late January build.
-
Originally posted by Trivial Psychic
This build locks up on me at 2 seconds mission time... in 2 attempts. Sorry WMCoolmon, but until a new build comes out where NO-ONE complains about a lockup, I'm gonna stick with PhReAk's late January build.
I've still got some lockup fixes that aren't in CVS yet, been testing them. So far every lockup that I have been able to reproduce is fixed. I don't want to put out a new build yet though (already enough of them) and I don't want to make WMCoolmon do a new build just for this so I'll PM you a link if you don't mind giving it a quick try.
-
PM recieved and build downloaded, though I may not be able to test this until Saturday. Thanks though.
-
Originally posted by Trivial Psychic
PM recieved and build downloaded, though I may not be able to test this until Saturday. Thanks though.
Not a problem. If it works ok let us know. I'll hold off on getting all of that in CVS until I know one way or the other. Though I've got a fealing that others might find the build and give it a test too. :)
-
I managed to find the time to test it just now, and it worked like a charm... it even has Bob's repair of the alt-tab!!! I experienced no lockups while testing this build. The only real problem I could see was the reversed scrolling direction for the ships and weapons in the preflight loadout and ship selection. This bug has already been reported in this thread. My advice is to commit your lockup fix.
One other thing... this may have been in other builds too, and I just haven't been able to test them to notice this, but has someone improved the thuster effects? I didn't see any clipping (though I only viewed 1 capital ship, a medical frigate) around the thrusters. Either way... this is good.
Until this fix is commited and someone creates a new build including it, yours will become my new build of choice, taking over for PhReAk's from late January.
Later!
-
Originally posted by Trivial Psychic
My advice is to commit your lockup fix.
Great! I need to get some sleep first but I'll commit when I wake up tomorrow (something like 3 and half hours from now :)).
One other thing... this may have been in other builds too, and I just haven't been able to test them to notice this, but has someone improved the thuster effects? I didn't see any clipping (though I only viewed 1 capital ship, a medical frigate) around the thrusters. Either way... this is good.
Umm, not sure. I know that there has been some work on thruster related stuff but I haven't kept track of it all. I think that Bobboau added something related to this but I'm not really sure what it was.
-
BTW: That feature, the alternative interface...is...wow. utterly incredible. I mean, I never saw this coming. I see things I've always wanted in FreeSpace 2 but never thought possible...they're now most likely possible. A Window based GUI for FreeSpace 2 mainly a la Unreal Tournament and Microsoft Flight Simulator, and of course most leading operating systems. Making the ESC key in mission bring up overlay menus featuring ALL features of the main hall, that way you don't have to exit your mission in progress to view the tech room, choose a different mission, change flags, etc. And last but not least I now dream of the ability to rearrange and resize HUD items, target ships, drag my throttle indicator to set speed, select weapons, etc. with my MOUSE, while I'm flying the ship with my joystick...
...I can dream *drools*
-
i hope THIS build works. :sigh: