doris-develop Mailing List for Doris - OpenGL scripting
Brought to you by:
trout
Menu
▾
▴
doris-develop — Discussion of development and usage.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(143) |
May
(6) |
Jun
(3) |
Jul
(2) |
Aug
|
Sep
|
Oct
(13) |
Nov
|
Dec
|
|
From: Nick T. <ni...@ro...> - 2004-10-18 19:14:45
|
Hey, I'm definitely going to check this out: http://www.devlib-central.org/ This looks like what I want... Nick |
|
From: Nick T. <ni...@ro...> - 2004-10-18 16:40:04
|
> > I'm in two minds whether to create a Doris2 project (or another > > project entirely) and do totally without GLUT and GLUI, but still > > having GL to do the rendering, leaving Doris (1) as it is. >=20 > That might not be a bad idea. For audio, you might want to look at > SAL (http://www.bookofhook.com/sal), it's much lighter weight than > bringing in SDL_mixer, but if you're using SDL already, it may not > make much of a difference either way. >=20 > For me it's not about the games, it's about a combination of having an > easy to use game framework AND tools framework, because when I'm > messing around with stuff the tool often IS the game -- separate tools > and games are an anachronism to some degree as far as I'm concerned. Okay, I think I'm going to create a new project. I'll leave Doris as GLUI, GLUT, GL with a toLua++ binding and start a new project. LuaGame? Bacon? :) Components in new project: * SDL - gfx, joystick * SAL/SDL_mixer - sound * Glbind.cpp - drawing - copied from Doris so don't have to maintain toLua stuff in new project. * enet - networking. * OpenDE - physics/collision. * Add some sprite library, particle system etc. * Some basic GUI library. What I like about using SDL is all the components there are to adopt and merge in. Probably do a manual Lua binding. Anyway, this is a longer term project. I should probably finish that q2x stuff first. Can I get CVS access? :) Nick |
|
From: Brian H. <ho...@bo...> - 2004-10-18 03:06:37
|
> I'm in two minds whether to create a Doris2 project (or another > project entirely) and do totally without GLUT and GLUI, but still > having GL to do the rendering, leaving Doris (1) as it is. That might not be a bad idea. For audio, you might want to look at SAL (http://www.bookofhook.com/sal), it's much lighter weight than bringing in SDL_mixer, but if you're using SDL already, it may not make much of a difference either way. For me it's not about the games, it's about a combination of having an easy to use game framework AND tools framework, because when I'm messing around with stuff the tool often IS the game -- separate tools and games are an anachronism to some degree as far as I'm concerned. Brian |
|
From: Nick T. <nic...@sh...> - 2004-10-18 02:38:37
|
Mmmmm, so where am I going to get a teapot from if I remove GLUT?! It looks like SDL and SDL_mixer could provide some nice functionality to Doris. I'm not sure about sticking with GLUI though. I mean, if you want a game prototyping system you don't really want to use GLUI. It might be useful for development, but perhaps not for the game. It would certainly cut down on the amount of work to do porting of GLUT. I'm in two minds whether to create a Doris2 project (or another project entirely) and do totally without GLUT and GLUI, but still having GL to do the rendering, leaving Doris (1) as it is. Hmmm, Nick |
|
From: Nick T. <nic...@sh...> - 2004-10-17 18:05:54
|
> I did some profiling of Doris because its running like a dog at the
moment.
Okay, I've done some selective inlining of vector constructors and
assignment functions, made the teapot a call list and this seems to have has
an effect. What does glutSetWindow do that it's the top abuser?!
simple.lua script:
Func Func+Child Hit
Time % Time % Count Function
---------------------------------------------------------
2246.281 27.6 2246.281 27.6 10022 _glutSetWindow@4 (glut32.dll)
1592.583 19.6 1593.201 19.6 204 tolua_gl_glCallList00(struct
lua_State *) (glbind.obj)
1277.548 15.7 2975.329 36.6 204 Window::display(void)
(doriswin.obj)
500.402 6.2 7446.505 91.6 1 _glutMainLoop@0 (glut32.dll)
315.488 3.9 315.488 3.9 1220
GLUI_Main::s_finish_drawing(void) (glui_main.obj)
314.137 3.9 314.137 3.9 1011
GLUI_Rotation::setup_texture(void) (glui_rotation.obj)
301.665 3.7 301.665 3.7 1 ___glutCreateWindowWithExit@8
(glut32.dll)
279.178 3.4 1807.712 22.2 526
GLUI_Master_Object::glui_motion_func(int,int) (glui_master_object.obj)
110.522 1.4 110.522 1.4 1011
GLUI_Rotation::draw_ball(float) (glui_rotation.obj)
100.715 1.2 100.715 1.2 6792 _glutBitmapCharacter@8
(glut32.dll)
98.585 1.2 98.585 1.2 1011
GLUI_Rotation::iaction_draw_active_area_ortho(void) (glui_rotation.obj)
|
|
From: Nick T. <nic...@sh...> - 2004-10-17 17:54:18
|
> Hmm, yeah, I looked in my archives, and you were generally okay with SDL, I must have mixed that up with something else you were opposed to because of size issues? It might have been the JPEG stuff? I ended up just putting the loading code in as I can't see why you'd want to save JPEGS from Doris (maybe BMPs but not JPEGs). > In the short run, I'd say that SDL support is by far the biggest step. May have a look at this today as its raining. > Sorry I haven't been able to contribute much, been busy with the bills and all =( Me neither, been pretty busy at work and had 2 hard drives melt down on me :(. I could do with getting that Q2X Lua work into a more secure place. Luckily I had it backed up on another drive, I lost a tonne of other stuff though. Nick |
|
From: Brian H. <ho...@bo...> - 2004-10-17 17:43:29
|
> I remember being against it. I can't find an email saying that! Hmm, yeah, I looked in my archives, and you were generally okay with SDL, I must have mixed that up with something else you were opposed to because of size issues? > http://www.novodex.com/ Ahhhh...yeah, if you want to go 3D, that would be nice to integrate. In the short run, I'd say that SDL support is by far the biggest step. Sorry I haven't been able to contribute much, been busy with the bills and all =3D( Brian |
|
From: Nick T. <nic...@sh...> - 2004-10-17 17:36:35
|
> I remember being against it. I can't find an email saying that! I don't > think SDL is that large from what I remember. I might have had another > reason for not using it initially. Oops, sorry, that should say "I don't remember..." :-/ |
|
From: Nick T. <nic...@sh...> - 2004-10-17 17:29:04
|
> Didn't we have this conversation already at some point, and you were against SDL because of its size? I remember being against it. I can't find an email saying that! I don't think SDL is that large from what I remember. I might have had another reason for not using it initially. I've been wondering for a while if stuffing all this into Doris is the right thing to do or if it should be just left as an OpenGL viewer and a new project started. But since noone seems to use Doris and it will still be an OpenGL viewer I don't see the harm. > I'm not familiar with Rocket. http://www.novodex.com/ Nick ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Doris-develop mailing list Dor...@li... https://lists.sourceforge.net/lists/listinfo/doris-develop |
|
From: Brian H. <ho...@bo...> - 2004-10-17 17:17:12
|
> I want to be able to prototype little games in Doris so I'd like > other features in SDL as well, e.g. joystick support, timers, etc. Didn't we have this conversation already at some point, and you were against SDL because of its size? > I started integrating enet for net support and I'd like to add > OpenDE for collision and physics. Perhaps I can add the Rocket > stuff as well? It's kind of an experiment. I'm not familiar with Rocket. Brian |
|
From: Nick T. <nic...@sh...> - 2004-10-17 17:12:39
|
I want to be able to prototype little games in Doris so I'd like other features in SDL as well, e.g. joystick support, timers, etc. I started integrating enet for net support and I'd like to add OpenDE for collision and physics. Perhaps I can add the Rocket stuff as well? It's kind of an experiment. Nick ----- Original Message ----- From: "Brian Hook" <ho...@bo...> To: <dor...@li...> Sent: Sunday, October 17, 2004 6:56 AM Subject: Re: [Doris] Doris profiling > I'm thinking of getting rid of GLUT and replacing it with SDL so > this might solve some of that problem and then we can use the font > rendering from that which I'd guess is faster? I'm not 100% sure if it's going to be faster, but as a general rule I would argue that SDL is going to be a superior alternative to GLUT under almost any situation since GLUT is poorly maintained and rarely used. Brian ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Doris-develop mailing list Dor...@li... https://lists.sourceforge.net/lists/listinfo/doris-develop |
|
From: Brian H. <ho...@bo...> - 2004-10-17 13:56:42
|
> I'm thinking of getting rid of GLUT and replacing it with SDL so > this might solve some of that problem and then we can use the font > rendering from that which I'd guess is faster? I'm not 100% sure if it's going to be faster, but as a general rule I would argue that SDL is going to be a superior alternative to GLUT under almost any situation since GLUT is poorly maintained and rarely used. Brian |
|
From: Nick T. <nic...@sh...> - 2004-10-17 07:52:50
|
I did some profiling of Doris because its running like a dog at the moment.
I used the VC6 profiler. I had to put an older graphics card (GeForce 2)
back in my development machine which could account for some rendering
sluggishness, but I don't remember the performance of GeF2s being that bad.
It looks like the problem is the GLUI rendering, more specifically, font
rendering. It looks like the font strings, or maybe each character should be
cached as a render list in GL to help speed things up.
I'm thinking of getting rid of GLUT and replacing it with SDL so this might
solve some of that problem and then we can use the font rendering from that
which I'd guess is faster?
Nick
----
Welcome to Doris 1.1.
Using Lua 5.0.2, Copyright (C) 1994-2004 Tecgraf, PUC-Rio
Executing Lua file: ..\bin\eg\test.lua
Profile: Function timing, sorted by time
Date: Sun Oct 17 00:35:22 2004
Program Statistics
------------------
Command line at 2004 Oct 17 00:34: doris ..\bin\eg\test.lua
Total time: 17850.373 millisecond
Time outside of functions: 61.117 millisecond
Call depth: 44
Total functions: 2163
Total hits: 2039061
Function coverage: 33.8%
Overhead Calculated 2
Overhead Average 2
Module Statistics for doris.exe
-------------------------------
Time in module: 17789.257 millisecond
Percent of time in module: 100.0%
Functions in module: 2163
Hits in module: 2039061
Module function coverage: 33.8%
Func Func+Child Hit
Time % Time % Count Function
---------------------------------------------------------
4978.986 28.0 4978.986 28.0 41169 _glutSetWindow@4 (glut32.dll)
3508.792 19.7 16696.134 93.9 1 _glutMainLoop@0 (glut32.dll)
1681.681 9.5 1681.681 9.5 153041 _glutBitmapCharacter@8
(glut32.dll)
1506.654 8.5 2224.340 12.5 160 Window::display(void)
(doriswin.obj)
840.191 4.7 840.191 4.7 3104
GLUI_Main::s_finish_drawing(void) (glui_main.obj)
589.025 3.3 589.025 3.3 1 ___glutCreateWindowWithExit@8
(glut32.dll)
569.454 3.2 570.428 3.2 320 tolua_gl_glCallList00(struct
lua_State *) (glbind.obj)
563.979 3.2 4008.939 22.5 975
GLUI_Master_Object::glui_motion_func(int,int) (glui_master_object.obj)
345.362 1.9 345.362 1.9 5070
GLUI_StdBitmaps::draw_bitmap(int,int,int) (glui_bitmaps.obj)
328.885 1.8 339.489 1.9 585
GLUI_Master_Object::glui_passive_motion_func(int,int)
(glui_master_object.obj)
323.850 1.8 323.850 1.8 1023
GLUI_Rotation::setup_texture(void) (glui_rotation.obj)
312.997 1.8 1939.253 10.9 9665
GLUI_Control_Presentation::s_draw_control_text(class GLUI_Control *,int,int)
(glui_control_presentation.obj)
279.306 1.6 404.588 2.3 1023
GLUI_Rotation::iaction_draw_active_area_ortho(void) (glui_rotation.obj)
177.079 1.0 177.079 1.0 2 _glutCreateSubWindow@20
(glut32.dll)
157.326 0.9 3237.962 18.2 512
GLUI_Master_Object::glui_display_func(void) (glui_master_object.obj)
120.541 0.7 120.541 0.7 1023
GLUI_Rotation::draw_ball(float) (glui_rotation.obj)
83.749 0.5 83.749 0.5 373152 vec2::operator[](int)
(algebra3.obj)
74.889 0.4 74.889 0.4 178440 _glutBitmapWidth@8
(glut32.dll)
64.175 0.4 979.097 5.5 1023
GLUI_Mouse_Interaction::draw_active_area(void) (glui_mouse_iaction.obj)
58.609 0.3 2768.308 15.6 10895
GLUI_Control::draw_recursive(int,int) (glui_control.obj)
54.129 0.3 55.194 0.3 160 tolua_gl_glClear00(struct
lua_State *) (glbind.obj)
52.663 0.3 1716.201 9.6 20548 _glutBitmapString(void *,char
const *) (glui.obj)
47.196 0.3 119.871 0.7 25124 _glutBitmapWidthString(void
*,char const *) (glui.obj)
44.390 0.2 44.390 0.2 127866 vec2::vec2(float,float)
(algebra3.obj)
43.905 0.2 167.292 0.9 13440 GLUI_Control::pack(int,int)
(glui_control.obj)
42.344 0.2 42.344 0.2 106155 GLUI_Node::node_next(void)
(glui_node.obj)
26.681 0.1 1777.242 10.0 1140 _luaV_execute (lvm.obj)
21.692 0.1 39.984 0.2 13035
GLUI_Control::get_this_column_dims(int *,int *,int *,int *,int *,int *)
(glui_control.obj)
21.447 0.1 21.447 0.1 98067 vec4::operator[](int)
(algebra3.obj)
21.033 0.1 21.033 0.1 4004
GLUI_Main::draw_raised_box(int,int,int,int) (glui_main.obj)
20.790 0.1 20.790 0.1 27270 _luaH_getstr (ltable.obj)
17.663 0.1 448.176 2.5 1218
GLUI_Listbox_Presentation::draw(class GLUI_Control *) (glui_listbox.obj)
16.654 0.1 34.779 0.2 973 operator*(class mat4 &,class
mat4 &) (algebra3.obj)
16.574 0.1 16.574 0.1 9009 _luaM_realloc (lmem.obj)
16.274 0.1 155.237 0.9 1228 GLUI_Panel::draw(int,int)
(glui_panel.obj)
15.988 0.1 15.988 0.1 44102 GLUI_Control::get_font(void)
(glui_control.obj)
15.924 0.1 15.924 0.1 9591 _glutGet@4 (glut32.dll)
15.858 0.1 37.361 0.2 15123
GLUI_Control::set_to_glut_window(void) (glui_control.obj)
15.375 0.1 19.283 0.1 1535
GLUI_Main::set_ortho_projection(void) (glui_main.obj)
14.992 0.1 16.855 0.1 1559
GLUI_Control_Presentation::s_draw_active_box(class GLUI_Control
*,int,int,int,int) (glui_control_presentation.obj)
14.863 0.1 479.005 2.7 1023
GLUI_Rotation::iaction_draw_active_area_persp(void) (glui_rotation.obj)
14.000 0.1 413.795 2.3 1509 GLUI_Rollout::draw(int,int)
(glui_rollout.obj)
13.927 0.1 65.391 0.4 13665
GLUI_Main::align_controls(class GLUI_Control *) (glui_main.obj)
13.560 0.1 13.560 0.1 1023
GLUI_Rotation::setup_lights(void) (glui_rotation.obj)
13.485 0.1 29.800 0.2 22114 _luaH_get (ltable.obj)
13.483 0.1 13.483 0.1 21248 _glutGetWindow@0 (glut32.dll)
12.455 0.1 33.952 0.2 2393
GLUI_Standard_Checkbox_Presentation::draw_active_area(class GLUI_Control *)
(glui_checkbox.obj)
12.052 0.1 92.243 0.5 17053
GLUI_Control::string_width(char const *) (glui_control.obj)
11.987 0.1 11.987 0.1 12704
GLUI_Control::set_to_bkgd_color(void) (glui_control.obj)
11.534 0.1 11.534 0.1 1509
GLUI_Control_Presentation::s_draw_emboss_box(int,int,int,int)
(glui_control_presentation.obj)
11.044 0.1 11.044 0.1 1023 GLUI_Main::set_viewport(void)
(glui_main.obj)
11.009 0.1 31.486 0.2 725
GLUI_EditText::draw_text(int,int) (glui_edittext.obj)
10.373 0.1 1241.646 7.0 669
GLUI_Main::check_subwindow_position(void) (glui_main.obj)
10.335 0.1 1731.570 9.7 7943 _luaD_precall (ldo.obj)
9.445 0.1 11.418 0.1 1628
GLUI_Main::find_control(int,int) (glui_main.obj)
9.445 0.1 11.131 0.1 24741 _luaA_indexAcceptable
(lapi.obj)
9.167 0.1 11.906 0.1 7599 _luaS_newlstr (lstring.obj)
8.713 0.0 69.381 0.4 706 GLUI_Spinner::draw(int,int)
(glui_spinner.obj)
8.202 0.0 8.202 0.0 18535 _negindex (lapi.obj)
8.161 0.0 1724.361 9.7 20548
GLUI_Control_Presentation::s_draw_string(char const *,void *)
(glui_control_presentation.obj)
8.089 0.0 26.438 0.1 15123 GLUI::s_restore_window(int)
(glui.obj)
7.939 0.0 48.982 0.3 13665 GLUI_Control::align(void)
(glui_control.obj)
7.931 0.0 7.931 0.0 44177 GLUI_Node::node_prev(void)
(glui_node.obj)
7.883 0.0 7.883 0.0 160 _glutWireCube@8 (glut32.dll)
7.848 0.0 16.103 0.1 1946
mat4::mat4(float,float,float,float,float,float,float,float,float,float,float
,float,float,float,float,float) (algebra3.obj)
7.781 0.0 7.781 0.0 35596 vec4::operator=(class vec4
const &) (algebra3.obj)
7.565 0.0 1174.593 6.6 977
GLUI_Control::execute_callback(void) (glui_control.obj)
7.373 0.0 568.285 3.2 2495
GLUI_Standard_Button_Presentation::draw_button_text(class GLUI_Control
*,bool) (glui_button.obj)
7.274 0.0 22.854 0.1 6369 _lua_pushlstring (lapi.obj)
7.017 0.0 98.755 0.6 973
Arcball::mouse_motion(int,int,int,int,int) (arcball.obj)
6.940 0.0 6.940 0.0 1218
GLUI_Control_Presentation::draw_box_inwards_outline(int,int,int,int,bool)
(glui_control_presentation.obj)
6.917 0.0 34.405 0.2 1946 quat::to_mat4(void)
(quaternion.obj)
6.772 0.0 6.772 0.0 31584 vec4::vec4(void)
(algebra3.obj)
6.451 0.0 34.366 0.2 3165 _luaV_gettable (lvm.obj)
6.430 0.0 2765.457 15.5 499
GLUI_Master_Object::glui_idle_func(void) (glui_master_object.obj)
6.338 0.0 6.338 0.0 1 ___glutInitWithExit@12
(glut32.dll)
6.274 0.0 128.330 0.7 973
GLUI_Rotation::iaction_mouse_held_down_handler(int,int,int)
(glui_rotation.obj)
6.152 0.0 3433.366 19.3 973
GLUI_Mouse_Interaction::mouse_held_down_handler(int,int,int)
(glui_mouse_iaction.obj)
6.148 0.0 11.762 0.1 2969 mat4::mat4(class mat4 const
&) (algebra3.obj)
6.075 0.0 76.630 0.4 977 Window::updateCB(int)
(doriswin.obj)
5.866 0.0 28.627 0.2 6285 _lua_pushstring (lapi.obj)
5.769 0.0 2451.696 13.8 557 GLUI_Main::refresh(void)
(glui_main.obj)
5.696 0.0 194.718 1.1 725 GLUI_EditText::draw(int,int)
(glui_edittext.obj)
5.352 0.0 12.454 0.1 1946
Arcball::mouse_to_sphere(class vec2) (arcball.obj)
5.318 0.0 15.995 0.1 4540 _lua_rawget (lapi.obj)
5.184 0.0 5.184 0.0 17407
GLUI_Control::get_int_val(void) (glui_control.obj)
5.172 0.0 1191.053 6.7 993
GLUI_Main::post_update_main_gfx(void) (glui_main.obj)
5.139 0.0 31.222 0.2 7486 _luaH_set (ltable.obj)
5.115 0.0 11.631 0.1 14141 _luaA_index (lapi.obj)
5.109 0.0 9.566 0.1 9226 _lua_type (lapi.obj)
4.937 0.0 766.463 4.3 2393
GLUI_Standard_Checkbox_Presentation::draw(class GLUI_Control *)
(glui_checkbox.obj)
4.651 0.0 4.651 0.0 19294 vec3::operator[](int)
(algebra3.obj)
4.534 0.0 4.534 0.0 2580 _glutPostRedisplay@0
(glut32.dll)
4.435 0.0 5.119 0.0 2114
GLUI_Master_Object::find_glui_by_window_id(int) (glui_master_object.obj)
4.362 0.0 906.912 5.1 669
GLUI_Main::pack_controls(void) (glui_main.obj)
4.317 0.0 1803.352 10.1 2103 _luaD_call (ldo.obj)
4.173 0.0 8.982 0.1 7180 _sweeplist (lgc.obj)
4.069 0.0 40.926 0.2 3165 _lua_gettable (lapi.obj)
4.001 0.0 4.001 0.0 1 _glutSolidTeapot@8
(glut32.dll)
3.993 0.0 7.103 0.0 1987 mat4::mat4(class vec4 const
&,class vec4 const &,class vec4 const &,class vec4 const &) (algebra3.obj)
3.967 0.0 7.175 0.0 3943 mat4::operator=(class mat4
const &) (algebra3.obj)
3.820 0.0 24.536 0.1 5741 _newkey (ltable.obj)
3.659 0.0 7.519 0.0 1074
GLUI_Control::output_live(int) (glui_control.obj)
3.620 0.0 3.620 0.0 17036
GLUI_Control::get_control_name(void) (glui_control.obj)
3.509 0.0 3.509 0.0 9004 _luaV_equalval (lvm.obj)
3.412 0.0 14.871 0.1 3094 GLUI_Panel::update_size(void)
(glui_panel.obj)
3.394 0.0 3.627 0.0 9880 _luaH_mainposition
(ltable.obj)
3.252 0.0 6.383 0.0 5066
GLUI_Control::char_width(char) (glui_control.obj)
3.231 0.0 9.226 0.1 160 tolua_glu_gluLookAt00(struct
lua_State *) (glubind.obj)
3.089 0.0 8.716 0.0 1609 _luaB_assert (lbaselib.obj)
3.002 0.0 4.695 0.0 2010
GLUI_Rotation::copy_float_array_to_ball(void) (glui_rotation.obj)
2.990 0.0 2.990 0.0 7943 _luaD_poscall (ldo.obj)
2.936 0.0 5.991 0.0 4138 _lua_tonumber (lapi.obj)
2.888 0.0 2.888 0.0 3213 _arrayindex (ltable.obj)
2.819 0.0 16.151 0.1 512
GLUI_StaticText_Presentation::draw(class GLUI_Control *)
(glui_statictext.obj)
2.815 0.0 586.873 3.3 2495
GLUI_Standard_Button_Presentation::draw(class GLUI_Control *)
(glui_button.obj)
2.749 0.0 21.760 0.1 47
GLUI_RadioButton_Presentation::draw(class GLUI_Control *) (glui_radio.obj)
2.697 0.0 4.331 0.0 357 _traversetable (lgc.obj)
2.674 0.0 2.674 0.0 669 _glutPositionWindow@8
(glut32.dll)
2.631 0.0 3440.236 19.3 975 GLUI_Main::motion(int,int)
(glui_main.obj)
2.551 0.0 21.089 0.1 3510
GLUI_Rollout::update_size(void) (glui_rollout.obj)
2.373 0.0 17.140 0.1 2932
GLUI_Checkbox::update_size(void) (glui_checkbox.obj)
2.355 0.0 22.967 0.1 2825
GLUI_Button::update_size(void) (glui_button.obj)
2.342 0.0 7.917 0.0 3609 _tolua_tonumber
(tolua_to.obj)
2.237 0.0 19.492 0.1 983
GLUI_Rotation::copy_ball_to_float_array(void) (glui_rotation.obj)
2.234 0.0 16.162 0.1 2076 _luaV_settable (lvm.obj)
2.129 0.0 2.452 0.0 4004 _luaH_getnum (ltable.obj)
2.079 0.0 17.156 0.1 599 _module_index_event
(tolua_event.obj)
1.990 0.0 4.133 0.0 4932 _lua_isnumber (lapi.obj)
1.983 0.0 1.983 0.0 23 _glutSetCursor@4 (glut32.dll)
1.979 0.0 10.171 0.1 994 mat4::mat4(void)
(algebra3.obj)
1.947 0.0 2.388 0.0 998 GLUI_Main::idle(void)
(glui_main.obj)
1.922 0.0 588.794 3.3 2495 GLUI_Button::draw(int,int)
(glui_button.obj)
1.899 0.0 4.617 0.0 4089 _tolua_isnumber
(tolua_is.obj)
1.864 0.0 1.864 0.0 1476 GLUI::set_to_bkgd_color(void)
(glui.obj)
1.786 0.0 1.786 0.0 4290 _lua_pushnumber (lapi.obj)
1.779 0.0 2.175 0.0 1687 _lua_toboolean (lapi.obj)
1.761 0.0 23.956 0.1 2064 _luaV_index (lvm.obj)
1.756 0.0 2.656 0.0 3605 _tolua_isnoobj (tolua_is.obj)
1.748 0.0 1.748 0.0 8377 _lua_gettop (lapi.obj)
1.736 0.0 9.728 0.1 731
GLUI_EditText::update_substring_bounds(void) (glui_edittext.obj)
1.687 0.0 1.687 0.0 5476 _lua_settop (lapi.obj)
1.667 0.0 768.130 4.3 2393 GLUI_Checkbox::draw(int,int)
(glui_checkbox.obj)
1.640 0.0 1.640 0.0 5857 _reallymarkobject (lgc.obj)
1.638 0.0 1.983 0.0 1946 operator/(class vec2 const
&,float) (algebra3.obj)
1.610 0.0 7.993 0.0 2193
GLUI_EditText::substring_width(int,int) (glui_edittext.obj)
1.609 0.0 5.818 0.0 1013 identity3D(void)
(algebra3.obj)
1.590 0.0 8.451 0.0 1446
GLUI_Listbox::update_size(void) (glui_listbox.obj)
1.583 0.0 2.235 0.0 2720 _lua_pushvalue (lapi.obj)
1.576 0.0 1.576 0.0 7948
vec4::vec4(float,float,float,float) (algebra3.obj)
1.565 0.0 51.612 0.3 1001 _lua_call (lapi.obj)
1.554 0.0 27.140 0.2 2119 _lua_rawset (lapi.obj)
1.549 0.0 4.974 0.0 986
GLUI_Control::set_float_array_val(float *) (glui_control.obj)
1.544 0.0 2.933 0.0 960 _next (lparser.obj)
1.521 0.0 1.521 0.0 4659 mat4::operator[](int)
(algebra3.obj)
1.399 0.0 1.996 0.0 1700 _lua_getmetatable (lapi.obj)
1.394 0.0 18.214 0.1 160 tolua_gl_glLight00(struct
lua_State *) (glbind.obj)
1.344 0.0 2.323 0.0 53 Window::reSize(int,int)
(doriswin.obj)
1.321 0.0 1.339 0.0 1 tolua_glu_gluSphere00(struct
lua_State *) (glubind.obj)
1.285 0.0 6.280 0.0 6 _sweepstrings (lgc.obj)
1.284 0.0 4.569 0.0 643 _numuse (ltable.obj)
1.280 0.0 1.549 0.0 480
tolua_gl_glPushMatrix00(struct lua_State *) (glbind.obj)
1.279 0.0 8.533 0.0 745 _lua_isusertype
(tolua_is.obj)
1.254 0.0 2.258 0.0 320 tolua_gl_glEnable00(struct
lua_State *) (glbind.obj)
1.219 0.0 14.220 0.1 643 _resize (ltable.obj)
1.197 0.0 1.197 0.0 2022 vec3::operator=(class vec3
const &) (algebra3.obj)
1.186 0.0 1.510 0.0 1946 operator-(class vec2 const
&,class vec2 const &) (algebra3.obj)
1.182 0.0 4.808 0.0 3146 _freeobj (lgc.obj)
1.180 0.0 449.357 2.5 1218 GLUI_Listbox::draw(int,int)
(glui_listbox.obj)
1.143 0.0 2.996 0.0 1740 _luaL_checkany (lauxlib.obj)
1.077 0.0 2.281 0.0 1823 _luaH_getany (ltable.obj)
1.041 0.0 397.254 2.2 112 GLUI_Main::reshape(int,int)
(glui_main.obj)
1.008 0.0 4.273 0.0 1065 _setnodevector (ltable.obj)
0.978 0.0 10.493 0.1 944
GLUI_EditText::update_size(void) (glui_edittext.obj)
0.957 0.0 0.957 0.0 878
GLUI_Spinner::update_size(void) (glui_spinner.obj)
0.955 0.0 0.955 0.0 2926 operator*(class vec3 const
&,class vec3 const &) (algebra3.obj)
0.943 0.0 0.943 0.0 1218
GLUI_Control_Presentation::draw_box(int,int,int,int,float,float,float)
(glui_control_presentation.obj)
0.922 0.0 0.922 0.0 2986 vec3::vec3(float,float,float)
(algebra3.obj)
0.877 0.0 1.076 0.0 160 doris_glLoadMatrixf(class
Matrix &) (glbind.obj)
0.852 0.0 17.938 0.1 512
GLUI_StaticText::draw(int,int) (glui_statictext.obj)
0.846 0.0 0.943 0.0 160
tolua_gl_glLoadIdentity00(struct lua_State *) (glbind.obj)
0.836 0.0 1.011 0.0 980 operator^(class vec3 const
&,class vec3 const &) (algebra3.obj)
0.809 0.0 4.057 0.0 640 _tolua_tofieldnumber
(tolua_to.obj)
0.794 0.0 0.794 0.0 2004 _luaZ_read (lzio.obj)
0.774 0.0 8.662 0.0 619
GLUI_Main::passive_motion(int,int) (glui_main.obj)
0.770 0.0 0.770 0.0 1946
Arcball::set_constraints(bool,bool) (arcball.obj)
0.765 0.0 1.559 0.0 2004 _ezread (lundump.obj)
0.758 0.0 4.285 0.0 160 _tolua_isnumberarray
(tolua_is.obj)
0.748 0.0 24.294 0.1 755 _callTMres (lvm.obj)
0.744 0.0 1.738 0.0 1011 quat::set(class vec3,float)
(quaternion.obj)
0.743 0.0 2.206 0.0 641
GLUI_StaticText::update_size(void) (glui_statictext.obj)
0.731 0.0 0.752 0.0 2453 _traverseclosure (lgc.obj)
0.728 0.0 0.728 0.0 725
GLUI_EditText::draw_insertion_pt(void) (glui_edittext.obj)
0.709 0.0 2.739 0.0 1524 _newlstr (lstring.obj)
0.707 0.0 1.382 0.0 160
tolua_gl_glShadeModel00(struct lua_State *) (glbind.obj)
0.689 0.0 12.483 0.1 1 _luaL_loadfile (lauxlib.obj)
0.683 0.0 488.651 2.7 59
GLUI_Master_Object::glui_reshape_func(int,int) (glui_master_object.obj)
0.680 0.0 44.864 0.3 43
GLUI_Control::translate_and_draw(void) (glui_control.obj)
0.674 0.0 5.557 0.0 422 _luaH_new (ltable.obj)
0.664 0.0 0.664 0.0 1576 _luaC_link (lgc.obj)
0.663 0.0 6.548 0.0 480
tolua_gl_glMultMatrix00(struct lua_State *) (glbind.obj)
0.655 0.0 3.053 0.0 731 _LoadString (lundump.obj)
0.654 0.0 0.654 0.0 1214 vec2::operator=(class vec2
const &) (algebra3.obj)
0.653 0.0 0.653 0.0 1946 vec2::vec2(class vec2 const
&) (algebra3.obj)
0.641 0.0 0.947 0.0 1356 _tolua_pushnumber
(tolua_push.obj)
0.634 0.0 0.864 0.0 480 doris_glMultMatrixf(class
Matrix &) (glbind.obj)
0.617 0.0 2.642 0.0 424 _addk (lcode.obj)
0.616 0.0 0.616 0.0 1992 _luaO_rawequalObj
(lobject.obj)
0.587 0.0 1.998 0.0 1070 _luaF_newCclosure (lfunc.obj)
0.572 0.0 0.926 0.0 480 tolua_gl_glPopMatrix00(struct
lua_State *) (glbind.obj)
0.572 0.0 0.572 0.0 2957 vec3::vec3(class vec3 const
&) (algebra3.obj)
0.569 0.0 0.779 0.0 39 GLUI_Column::draw(int,int)
(glui_column.obj)
0.564 0.0 0.564 0.0 42
GLUI_Bitmap::load_from_array(int const *) (glui_bitmaps.obj)
0.562 0.0 7.324 0.0 640 _tolua_pushfieldnumber
(tolua_push.obj)
0.560 0.0 5.747 0.0 10 _propagatemarks (lgc.obj)
0.556 0.0 0.556 0.0 828 _hashnum (ltable.obj)
0.551 0.0 13.054 0.1 680 _tolua_constant
(tolua_map.obj)
0.539 0.0 1.833 0.0 160 tolua_gl_glTranslate00(struct
lua_State *) (glbind.obj)
0.533 0.0 0.533 0.0 210 _luaO_str2d (lobject.obj)
0.526 0.0 0.526 0.0 42
GLUI_Control::GLUI_Control(void) (glui_control.obj)
0.522 0.0 7.429 0.0 788 _lua_settable (lapi.obj)
0.513 0.0 9.484 0.1 745 _tolua_isusertype
(tolua_is.obj)
|
|
From: Nick T. <nic...@sh...> - 2004-07-14 19:45:41
|
> So this Komodo IDE is fairly nice. The personal edition is only $30 > as well. Just thought I'd mention it. I think Python is probably > better for large scale application development, but I'm still not sure > if I'm up to learning a whole new language _again_... I tried Komodo and thought it was more of a CGI/web development tool, although it has a nice stable debugger. I usually use the PythonWin IDE (which has a simple debugger) or SciTE to edit Python. When I'm doing Python GUI work I use Boa-Constructor (and wxWidgets). Boa-Constructor is a full Python IDE (GUI editor and target debugger), written in Python. Try the CVS version on SF. I think I might try the ActiveState Python .net editor/debugger next as Komodo didn't seem quite right or worth the difference between PythonWin IDE and the commercial price. Learning Python is definitely worth doing. If you learn C++, Lua and Python you'll be a fully equipped games programmer. Python is excellent for tools programming (XML, quick GUI apps, text parsing, tool chains etc) and a lot of games pipelines are moving in this direction. Lua, as you know, is great for embedding and runtime shinanagans and C++ is good for the core architecture and other faster more structured stuff. Each has its strengths and weaknesses but together, if used appropriately, can increase productivity significantly. > I think you were waiting on me for something with GLUI, but I can't > recall what it was? I think it was updating the toLua binding. You changed the GLUI stuff but modified the glue code by hand. I generally regenerate all of the bindings automatically before a release to make sure everything is working (which I assume won't work now). You might be able to use a diff/merge tool to do this fairly quickly (i.e. merge glui.pkg and glui.h ??). Nick |
|
From: Brian H. <ho...@bo...> - 2004-07-13 01:36:30
|
So this Komodo IDE is fairly nice. The personal edition is only $30 as well. Just thought I'd mention it. I think Python is probably better for large scale application development, but I'm still not sure if I'm up to learning a whole new language _again_... I think you were waiting on me for something with GLUI, but I can't recall what it was? Brian |
|
From: Brian H. <ho...@bo...> - 2004-06-01 20:09:36
|
> It won't default to nil if something isn't found, which is an > advantage and does mean it will flag unfound vars. Ah, okay, that's a pretty major advantage. > won't get much more static analysis at compile time than Lua. Some > people don't like the scooping of Python either. I do find Python > more robust than Lua and trust it much more for large scale > projects however its speed performance and bulk put it more in > "heavyweight" scripting category. I like both Python and Lua and > see a need for both. Right, Lua for scripting and Python more for application development/prototyping. > Did you finish the GLUI stuff? Hah! Surely you jest =3D) I'll try to look into it again soon, but I got distracted with PyGame... Brian |
|
From: Nick T. <ni...@ro...> - 2004-06-01 18:24:10
|
> I had a look at Python finally. Hmmm, don't really see much of an > advantage over Lua, vis a vis typing/typos =3D/ It won't default to nil if something isn't found, which is an advantage and does mean it will flag unfound vars. However, you won't get much more static analysis at compile time than Lua. Some people don't like the scooping of Python either. I do find Python more robust than Lua and trust it much more for large scale projects however its speed performance and bulk put it more in "heavyweight" scripting category. I like both Python and Lua and see a need for both. I still need to finish off my networking code in Doris but have been busy out doing non-computery stuff of late, and a lot of work. After that I fancy integrating ODE into Doris. But I may go back to q2x before ODE stuff. Did you finish the GLUI stuff? Nick |
|
From: Brian H. <ho...@bo...> - 2004-06-01 17:33:33
|
I had a look at Python finally. Hmmm, don't really see much of an advantage over Lua, vis a vis typing/typos =3D/ Brian |
|
From: Nick T. <nic...@sh...> - 2004-05-04 07:21:06
|
> Off the top of my head, no, but it's the kind of thing where you only
find out the limitations after a LOT of people have messed with it.
Did a first pass on binding. Its not passing values yet, just connecting.
Spent an hour or so trying to debug the damn thing when it wouldn't connect
and then after trying it with old code it worked??? Since I've no idea what
I did with the code I can only assume that the underlying network code
locked up somehow and then unlock itself? Possibly! :-/
Anyway, dammit I was hoping to get values passed tonight, but no luck.
Started trying to prototype the API (see attachment).
Something like this:
server = net.createServer(port)
server:onConnect( function (client_table) ... end )
server:onDisconnect( function (client_table) ... end )
This could also be done:
server = new.createServer( port = NB,
onConnect = function (client_table) ... end,
onDisconnect = function (client_table) ... end,
etc.
}
or both mechanism could be provided with a wrapper?
---- client ----
client = net.createClient("address", port [, timeout] )
Not quite sure how to do the values. Maybe: each client has an output table,
when a value changes in it, it is replicated in the client table at the
server. The server can chose to read new values and blank them out (so it
knows they are new), then it may chose to send or broadcast to the clients.
The server could just send value pairs as putting values in a table doesn't
seem to have much advantage? The client receives values in a table.
Alternatively there could be one table on each client and one for each
client on the server. Tables on client are synced on server, then server
changes values and they are synced back. Mechanism knows internally what are
client and what are server values to stop thrashing.
Mmm, too tired now.
Laterz,
Nick
|
|
From: Brian H. <ho...@bo...> - 2004-05-03 14:59:54
|
> Do you think this would be too limiting? Off the top of my head, no, but it's the kind of thing where you only find out the limitations after a LOT of people have messed with it. Brian |
|
From: Nick T. <nic...@sh...> - 2004-05-03 07:14:03
|
Did a little bit of work and checked it in. There's not Lua binding yet. I was trying to write some enet wrapper code, which I'll then bind to Lua. You can just start a server, then connect and disconnect a client at the moment. I was thinking to keep it simple you'd just implement a client server architecture. You start a server somewhere, clients join, they have networking tables. When they change values in their tables it's passed back to the server. The server decides what to broadcast by passing values into a table on the client(s). The game/application could be run on the server, so the clients may just pass mouse position and keys back and then the server decides object events etc and passes these on. Do you think this would be too limiting? I suppose this could be supplied as the default networking model, and if anyone wants anything more complicated in the future, an enet binding could be provided? Numbers and strings would be easy to replicate. I'm thinking tables and code could be replicated by the Lua source being passed on and executed on the target. User data and threads would be barred. Nick |
|
From: Nick T. <nic...@sh...> - 2004-05-01 19:11:49
|
>> A debugger would help.
>ya think? =)
I wouldnt mind one for q2x either. I wonder if we could revive a VisualLua
one? We have one at work but obviously we can't use that. That one is
written in Python ;-). Actually there is a really basic debugger with wxLua.
I wonder if that would be the best route?
>> The tolua system saves a lot of manual work.
> But that works has been done already with the first pass, right?
I've found it just as easy to update the package file in the past, as it is
to put lots of markers in your header, but each to his own. Sometimes you
change prototypes because of parsing problems in the package. I find it
easier and quicker to just go through a file with lots of stuff commented
out.
> I would prefer that, immensely. It's just far too easy to have the
.pkg and .h files diverge.
The following is an example from the tolua++ docs. Why don't you try this:
// tolua_export -- export one line
//tolua_begin
-- exports between the markers
// tolua_end
----->8----->8----->8----->8----->8----->8----->8--
#ifndef EXAMPLE_H
#define EXAMPLE_H
class Example { // tolua_export
private:
string name;
int number;
public:
void set_number(int number);
//tolua_begin
string get_name();
int get_number();
};
// tolua_end
#endif
----->8----->8----->8----->8----->8----->8----->8----->8--
> This could be presented as an additional tool. I don't really find
> the existing system that much of a hassle.
That's because you use Python =)
> these are entirely optional. I don't think the Lua parser or
> compiler should be, or needs to be changed.
> How would you add classes that would generate static compile time
errors without modifying the parser?
You could do it as a preprocess. I think a debugger would probably be the
most useful thing though. Once you get used to it, not have strong type
checking really isn't a problem. There are lots of Python docs and users
which say the same.
Nick
|
|
From: Brian H. <ho...@bo...> - 2004-05-01 01:07:38
|
> A debugger would help. ya think? =3D) > The tolua system saves a lot of manual work. But that works has been done already with the first pass, right? > Tolua does present a mechanism to parse the .h files directly and > only take out the bits you want, but you have to add // tolua_start > // tolua_end style markers all over the place. I would prefer that, immensely. It's just far too easy to have the .pkg and .h files diverge. > Back end? Do you mean start up GL? I pretty sure there is code to > do that in SDL. Is SDL that much hassle to get going? Please expand. It's not difficult, it's just gotta be done. So anywhere there are glut calls, you have to convert to SDL calls, etc. Maybe I'm making too big a deal out of this, but that's partly because I've never actually had to write SDL code directly =3D) > This could be presented as an additional tool. I don't really find > the existing system that much of a hassle. That's because you use Python =3D) > these are entirely optional. I don't think the Lua parser or > compiler should be, or needs to be changed. How would you add classes that would generate static compile time errors without modifying the parser? Brian |
|
From: Nick T. <ni...@ro...> - 2004-05-01 00:39:31
|
> > I think it's because Lua defaults the value to nil if it doesn't > > find something, whereas Python recognises that its a typo. You can > > change Lua to find none existant globals using a metamethod, > > perhaps just in the debug version. Should we add this as an option > > to Doris? >=20 > Possibly, but it only sort of helps -- you still have to find the > error at run-time, and you have to go through some hoops when you DO > want to declare a global variable. It changes things enough that it > sort of stops being a Lua program. A debugger would help. > > One thing you need to do is update the GLUI packages in Doris so > > the binding can be auto generated. What else do you see will take > > all this time? > I can't stand the .pkg system. I really dislike tolua() and would > prefer to use manual bindings, to be honest. Having two sets of > headers is silly, and having it export all by default is also silly. I > would much prefer to do something like a tag for exporting to Lua, > e.g. > LUA_EXPORT void function( void ); > Is something like this possible? The tolua system saves a lot of manual work. You just have to go through and edit the interface you want to present in Lua and it does the rest for you, and all the error checking. Writing large bindings is tedious. If there were some benefit, like you want to do some clever Lua stuff then it might worth doing. For example, with enet I'd like to try doing the write to a table and it replicates idea, so there is a benefit to hand coding here. GUI APIs are just calls though and there is little benefit to hand coding. I'd say go ahead and hand code it if you like, but then if you didn't maintain it, I would have to, and I don't want to, so I'm not going to say hand code it! :) Tolua does present a mechanism to parse the .h files directly and only take out the bits you want, but you have to add // tolua_start // tolua_end style markers all over the place. This would then mean that if you redistributed this code it would contain these markers. It really doesn't take that long to do it by hand. The reason why I do it manually in this case is because I've tried other solutions and they just make the code look ugly and complicated and it doesn't save any time. In q2x I wrote a python script to generate bindings and declare variables, but this is really just to help with the conversion to Lua. Once this work is done the script will/should no longer be necessary. > > What needs doing? I thought you'd just have to swap over the half > > dozen callbacks to let the widgets operate and set GL up. I'm > > pretty sure there is code to use GL with SDL already. What else > > needs doing? >=20 > Well, all the back end stuff has to get going as well. Back end? Do you mean start up GL? I pretty sure there is code to do that in SDL. Is SDL that much hassle to get going? Please expand. > > I think some sort of class support and more though about modules > > and structure, using support from function environments, needs > > adding at this point. These could be offered as part of Doris? >=20 > I was envisioning a type system that could be done almost entirely > with a preprocessor, something like: This could be presented as an additional tool. I don't really find the existing system that much of a hassle. I thing the best solution is to provide a couple of util libraries which provide global checking and class support, and perhaps preprocessing and these are entirely optional. I don't think the Lua parser or compiler should be, or needs to be changed. Nick |
|
From: Brian H. <ho...@bo...> - 2004-04-30 23:06:46
|
Crap, I typed a response to this and it got ate by my mailer
somewhere. Anyway...
> You mean just playing around?
Yes.
> I think it's because Lua defaults the value to nil if it doesn't
> find something, whereas Python recognises that its a typo. You can
> change Lua to find none existant globals using a metamethod,
> perhaps just in the debug version. Should we add this as an option
> to Doris?
Possibly, but it only sort of helps -- you still have to find the
error at run-time, and you have to go through some hoops when you DO
want to declare a global variable. It changes things enough that it
sort of stops being a Lua program.
> ..which is incredibly slow. I've never liked Java.
Agreed, but with GL this isn't an issue. If you write the widgets one
time they should work everywhere the same.
> One thing you need to do is update the GLUI packages in Doris so
> the binding can be auto generated. What else do you see will take
> all this time?
I can't stand the .pkg system. I really dislike tolua() and would
prefer to use manual bindings, to be honest. Having two sets of
headers is silly, and having it export all by default is also silly. I
would much prefer to do something like a tag for exporting to Lua,
e.g.
LUA_EXPORT void function( void );
Is something like this possible?
> What needs doing? I thought you'd just have to swap over the half
> dozen callbacks to let the widgets operate and set GL up. I'm
> pretty sure there is code to use GL with SDL already. What else
> needs doing?
Well, all the back end stuff has to get going as well.
> I think some sort of class support and more though about modules
> and structure, using support from function environments, needs
> adding at this point. These could be offered as part of Doris?
I was envisioning a type system that could be done almost entirely
with a preprocessor, something like:
deftype $vec2 =3D
{
x =3D "number", y =3D "number"
}
function add_vecs( $vec2 a, $vec2 b )
return $vec2{ x =3D a.x + b.y, y =3D a.y + b.y }
end
The preprocessor can easily type variables if a type exists, and if
none exists it just works like old fashioned Lua.
Doing:
$vec2 a =3D $vec2:new()
a.z =3D 3 -- generates compile time error
Modifying the lexer to ignore all "$" would be pretty easy I think as
well.
Brian
|
