Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
New menu system
04-24-2006, 04:24 AM,
#46
 
The menus now (r972) load their option data mostly from options.config. A good bit of code has been added to the Gui and SETTINGS classes to do this. The good news it seems to work! Smile The dynamically loaded options like resolutions, cars, tracks, etc. all work now. All of this greatly simplifies lots of things, not least of which is menu maintenance.

note: The SETTINGS class does not take full advantage of the new options data, for instance I will probably later make settings.Get( ... ) and settings.Set( ... ) use the options data to check types instead of the local vectors I've been using. Also I'll probably use the default values in the options data instead of those in data/settings/VDrift.config in the future.

Please continue testing the new menus and keep posting bugs...I'm sure all this will add a few... :roll:
Reply
04-24-2006, 04:46 AM,
#47
 
r975 fixes a bug where when pressing escape, the cancel button isn't released unless the mouse is over it.

Remaining bugs/fixes needed in menus:
* Joystick calibration routine still needed so joystick axes can be assigned, etc.
* Only first three controls can be accessed bug still there
* No way to record or play a replay
* The controlgrab widgets' icons need some text overlay with key name, button number, etc.
* A few more options need to be added to options.config
* SETTINGS class should take full advantage of options.config
* textboxes sometimes seem funky
* some kind of checking should be done on controls to prevent double-assignment
Reply
04-24-2006, 02:53 PM,
#48
 
great progress!

anyhow, i'm having problems when changing display options now:

Thread 0 Crashed:
0 org.vdrift-team.vdrift 0x0008b8f8 TEXTURES::Load(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, int&, int&) + 64 (basic_string.h:585)
1 org.vdrift-team.vdrift 0x0002d20c PARTICLE::Load() + 224 (textures.h:73)
2 org.vdrift-team.vdrift 0x000170e8 ChangeDisplay(int, int, int, bool, bool) + 924 (main.cpp:374)
3 org.vdrift-team.vdrift 0x000174d4 ReloadDisplay() + 816 (basic_string.h:480)
4 org.vdrift-team.vdrift 0x000a8afc VGUI::Gui:TonguerocessAction(std::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 272 (gui.cpp:2810)
5 org.vdrift-team.vdrift 0x000a97b0 VGUI::Gui::MouseRelease() + 376 (gui.cpp:2608)
Reply
04-24-2006, 03:15 PM,
#49
 
I thought you might find that one! I ran across it last night but like this:
Code:
(gdb) bt
#0  0xb7d509cb in std::string::compare () from /usr/lib/libstdc++.so.6
#1  0x08054632 in std::operator==<char, std::char_traits<char>, std::allocator<char> > (__lhs=@0x1c, __rhs=@0xbfedb110)
    at basic_string.h:2075
#2  0x0809ab1a in TEXTURES::Load (this=0x8164ca8, newtexfile=
        {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x8797a5c "hud/timerbox.png"}}, mipmap=false, w=@0xbfedb128, h=@0xbfedb124)
    at src/textures.cpp:126
#3  0x080582e9 in TEXTURES::Load (this=0x8164ca8, newtexfile=
        {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x0}}, mipmap=false) at textures.h:73
#4  0x0809babb in TIMER::Load (this=0x8167f80) at src/timer.cpp:190
#5  0x0804e360 in ChangeDisplay (w=1024, h=768, bpp=16, fullscreen=false, reloadtextures=true) at src/main.cpp:375
#6  0x0804e8f4 in ReloadDisplay () at src/main.cpp:413
#7  0x0811ca68 in VGUI::Gui::ProcessAction (this=0x869b6e0, action=
        {static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0x88d6194 "ReloadDisplay"}}) at src/gui/gui.cpp:2808
#8  0x0811c17c in VGUI::Gui::MouseRelease (this=0x869b6e0) at src/gui/gui.cpp:2608
#9  0x08053711 in main (argc=1, argv=0xbfedb4a4) at src/main.cpp:2323
(btw if you compile with -g3 you get all that nice extra debug info.)

So for me, it crashes when TIMER::Load tries to reload its textures after a display change. For you, it looks like i'ts crashing when reloading Particle textures. Why mine makes it through loading particles but yours doesn't is beyond me...but it seems like this is a bug with the TEXTURES class.
Reply
04-24-2006, 06:57 PM,
#50
 
If I insert a line that reads
Code:
cout << curnode->texfile << endl;
at src/textures.cpp:126, then recompile and run VDrift, I get lots of printouts every time a texture is loaded, since this function searches through the textures that have already been loaded to see if it should return an already loaded texture id number.

When I go to Options :arrow: Display and change the resolution or something and then press OK, here's what I get:
Code:
gui/newfontt3.png
weather/star.png
gui/newfontt3.png
weather/raindrop.tga
weather/star.png
gui/newfontt3.png
weather/clouds.png
weather/raindrop.tga
weather/star.png
gui/newfontt3.png
weather/moon.png
weather/clouds.png
weather/raindrop.tga
weather/star.png
gui/newfontt3.png
smoke/particle0.png
smoke/particle1.png
smoke/particle2.png
smoke/particle3.png
smoke/particle4.png
smoke/particle5.png
UP
Don't ask me what that bit of garbage at the end there is... Smile it looks like either something else has overwritten the memory here or there is a null pointer (which shouldn't happen...)
Reply
04-25-2006, 04:32 PM,
#51
 
...or maybe, somehow the delete function isn't working properly, and it is leaving empty nodes in the list. Either way I can't track it down...I'm tempted to rewrite TEXTURES using an STL list or vector instead of a linked list and see if that makes any difference. This might result in some performance loss but since this class isn't referenced that often in areas other than loading, I don't think it will matter much. This would remove any doubt about how well the the implementation of the linked list works, and perhaps fix the bug in the process.

Oh yeah, and I fixed a little bug causing the framerate not to be displayed when the game starts, and options.config'd the Music Volume option.
Reply
04-26-2006, 03:39 AM,
#52
 
Alright, I rewrote the TEXTURES class to use an STL list of a new class called TEXTURE, that is a lot like the old TEXTURENODE class (it holds the same data). The biggest difference between TEXTURE and TEXTURENODE is that data members in TEXTURE are private (accessible through public Get functions). Using this rewritten TEXTURES class, VDrift does not crash when the display settings are changed and the textures are reloaded. Big Grin

Please test this on other platforms. It's in SVN r980.
Reply
04-27-2006, 10:41 AM,
#53
 
it *mostly* works fine now, but when i'm in fullscreen and just change the viewing distance and nothing else, i just get a white screen...

it's also great to see the FPS counter back ;o)

while we are at it, do you also have visual artifacts around the FPS counter?
Reply
04-27-2006, 12:23 PM,
#54
 
I don't see any artifacts around the FPS counter, nor does my screen go all white when I change texture sizes. However for some reason (I think having to do with my sound) the game now segfaults on exit, backtrace reveals a bunch of stuff about trying to delete sound sources. Not sure if this is really a bug or just something on my end, but it's certainly weird and annoying.
Reply
04-28-2006, 12:44 AM,
#55
 
The segfault on exit thing cleared up, guess it was something on my end...
Reply
04-29-2006, 05:30 PM,
#56
 
thelusiv Wrote:[...] nor does my screen go all white when I change texture sizes

heh, i said nothing about /texture sizes/, it occurs (reproducibly) when changing the *viewing distance* (and nothing else)...

any idea about how i'd start debugging that?
Reply
04-30-2006, 04:23 AM,
#57
 
abs1nth Wrote:heh, i said nothing about /texture sizes/, it occurs (reproducibly) when changing the *viewing distance* (and nothing else)...

any idea about how i'd start debugging that?
hehe, oops. i noticed that you said view distance later (not sure where I got texture size...) and checked that too, it's fine also. Not sure what might cause it...does this happen when you change any other values in display options?


btw, I just checked in the beginnings of the joystick calibration routine. the data capture and drawing code is there. drawing code needs a little more work, and it does not yet save the values to the global game calibrations or enable joystick movement.
Reply
05-03-2006, 03:47 AM,
#58
 
The Calibrate widget is now mostly done (r987). It draws the way I want it to, minus the text it needs to display. Currently it displays up to three grids, each representing two axes. You can move your joystick axes around and see the cursor move around on the grid. There is no visual cue yet for where the calibration points are set, this needs to be done. It was tricky to do this, but I made it so that if you haven't moved any axes yet, it doesn't display anything. if you move one stick (two axes) it will display only one grid and cursor. If you move another stick it splits into two grids with two cursors, one for each stick.

Screen shots:
before movement
after movement of 1 joystick (2 axes)
after movement of 2 joysticks (4 axes)

Bugs:
* for some reason joystick move events are not generated when the joystick is at 0, so the joystick cursor never actually crosses the grid axes.
* if you mouse over the cancel or ok button the calibrate widget no longer responds to joystick movement
* the gui is not yet aware when a calibration has been done, so it still doesn't allow you to add joystick controls or use the joystick in the menus even though you've calibrated.

Stuff to add:
* a way to change to and calibrate the next joystick(s), if there's more than one
* text displaying which axes are where
* some sort of visual cue showing where the upper and lower boundaries have been set
* in-game joystick calibration menu needs to be added
* it'd be nice if the calibration widget reacted to the joystick deadzone so you can get a feel for how much of the stick range is usable before playing
Reply
05-04-2006, 12:00 AM,
#59
 
The 3 calibrate bugs mentioned in my last post have been resolved plus some other things. I have also modified SETTINGS some to take full advantage of the new options.config file. These changes are all in r991. All the stuff above that I need to add is still pending.

Other remaining things to fix regarding menus:
* Only first three controls can be accessed bug still there
* No way to record or play a replay
* The controlgrab widgets' icons need some text overlay with key name, button number, etc.
* textboxes sometimes seem funky
* some kind of checking should be done on controls to prevent double-assignment
Reply
05-04-2006, 03:02 AM,
#60
 
In SVN r992 all the "stuff to add" from 2 posts ago is fixed, except for a way to change to and calibrate the next joystick(s). Actually, the way it works now, if there are two joysticks being calibrated at the same time, it will draw one joystick's set of axis grids on top of the other one. I plan to add a wheel widget that lists all available joysticks and switches the calibration grids between then when changed. The only other thing mentioned as needed 2 posts ago was some some visualization or something of the deadzone, but I'm going to hold off on this one, because I realized it's a lot more complex than I thought... :?

Also I fixed the bug that only allowed the first three controls in a controlgrab to be clicked on. Now the clickable area is extended to fit any number of controls.

gui todo list
* replays (record/play)
* text overlay for controlgrab icons
* textbox voodoo magic
* control double-assignments...
* prettier multiple joystick calibration

p.s. no I don't plan to implement car parts yet, I want to wait until the new game world/player system is set up...
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)