m15 module

[kryton9]

Petr, I am finally getting back into programming and had a question. I am going to work on a new model viewer written in c++ using wxwidgets. I want to of course want to load m15 files.

I had some questions.
1. Since you already have routines to load and optimize m15 files, can I just call those functions from a dll that you make in powerbasic and that I can call in c++?

2. If #1 is not possible, can you give me some guidance on what I might put into a c++ class for handling m15 files?

I will put up a rough download later tonight that just draws a wireframe cube, but to give you an idea of what I am doing and a first glimpse at the very early stages of a new model viewer/level editor.

[kryton9]

I had a thought while coding tonight... since it might be possible that thinStudio 3D Level Editor Viewer (thinStudio3DLEV) might be added onto by others. I thought maybe we should agree on which language and IDE to use.

thinStudio3DLEV will be an opengl panel in a window that has regular windows GUI items around it.

Possible choices:
Delphi 6 (costs not too much these days if you can find it)
TurboDelphi Free Edition (this is free) (this needs .net, so hence Delphi 6 as I know Mike, Petr and I have it)
FreePascal Lazarus Edition (this is free)
wxDevC++ (what I started with tonight) (this is free)

As you can see I am looking for something that can compile and supports a nice graphical form designer.
I am open to other application suggestions, these just came to my mind.

I am interested in starting the program and developing it to a point to pass it on to another developer after I add these features.

Selecting and setting up skybox/skydome if needed.
If no skybox/skydome then providing different backgrounds frameworks.
Loading of m15 objects.
Placing lights, cameras and trigger objects (triggers would be implemented by probably Mike since he developed the cool event manager)
Full control of placement, rotation, scale and possible path animation of all objects in a level.
Selecting control systems, keyboard, gamepad or joystick
All of the things in the level editor viewer would have access to GUI based property controls.
All info for the level would be saved out to a file to be loaded by the game developer.

When I am done, any user could probably develop a real time 3D movie type of scene that would playback like a walk through or fly through.
Maybe even one item could be setup as the control object for the input device on playback. All of this info would be saved out to a file.

Hand off for possible features to be added to by other programmers:
Triggers (Event Handling)
Special Effects Handling
Artificial Intelligence for units

I guess it makes sense to select an application we would all like to use and have.

Maybe we can add applications to a poll and see which is most popular and that we all have.

Just had another thought too, that is to use Blender for the viewer editor and perhaps all of use work in python and write
an export level script that can be read by a program written in thinBasic that could react to the dynamic effects, like animation.

Open and looking forward to any feedback.

[Petr Schreiber]

Hi Kent,

what a big project. I now have to finish some work, but during late afternoon/night I will reply here.
To answer just something :) - it is possible to interface C++ with PB/DLL, but not with thinBASIC module DLL of course.
The documentation for file format is here (http://psch.thinbasic.com/data/thinEdgeM15_fileformat.pdf), but I could write a DLL for you if you want.

The final scene in thinBASIC could be handled by TBGL/Entities ( as they support maintaining for arbitrary number of lights, while just 8 can be on ) and definitely with TBEM module. Maybe if there would be tiny code editor, where we could add code snippets for each object? ( like in Delphi for controls )


Thanks, more later,
Petr

[kryton9]

I was thinking more this editor would just create the text file as in an ini file or xml.
It would just make loading and placing things into a scene and sort of work in real time in a 3d environment to set properties with visual feedback.

Then thinBasic would be used to create the application (game, demo, fly through) but all of the level (scene) info would be loaded from the text file created by the editor.

There are actually at least 2 parts, so as not to get confusing... 1.) the editor (developed by us in a compiled language or python if we go the blender route).

The second part is not in our hands, but 2.) the programmer wanting to use the files created by the editor. They would use thinBasic for this.

So for us is to determine which language or way to go for part 1.


It might be nice to have a dll as it is something you could probably do quickly in powerbasic since the code is already there. This way any user could use m15 files in whatever language that can access dlls. As you know I wrote a loader in Delphi, but it didn't optimize or figure out the normals, stuff I know you already figured out.
So no sense reinventing the wheel when you have it. So when you have time a dll would be nice.

I haven't seen Mike on here lately, maybe he is on vacation... I guess we should wait to hear from him also and anyone else interested in working on this.

[Petr Schreiber]

Hi Kent,

yes, you are right with separation to 2 projects.
I am looking forward to work on 2), the 1) is tricky :)

Language for 1) ... up to you :) Lazarus is not bad at all, but superlong compile times ( at least on my PC ) are a bit frustrating. I guess I would take the role of "support coding", like the DLL and/or thinBASIC loading of scene.

You know me, for 1) from compilers I would choose PowerBASIC :D but I guess the dialog design part would be too frustrating comparing to Delphi.

I cannot speak much of C++, as my knowledge of it is as big as the one about Spring habits of Inuits :)

So its up to you, I think you like Delphi quite a lot ( and know a lot about it ) and if Mike will develop FantomGL somewhere in future ( as he likes Pascal too ), we could port it to that. After reliable interpreter ( thinBASIC :) ) we would have also compiler where we know whats going on.

I am sorry to not see Mike here for longer time, hope he is ok.


Petr

[ErosOlmi]

I am sorry to not see Mike here for longer time, hope he is ok.

Every now and then he is present here. Maybe busy with other stuff.

[kryton9]

Petr I dreamed about the project while sleeping... we could do it all in thinBasic. In order to do it, we need to have an opengl screen along with a panel to place controls on to.

The other thing is to have an opengl screen with 2 viewports. 1 viewport 3d and the other 2d for controls.

This way having these kind of options will make many different types of application development possible in thinBasic.

So the question is how best to go about doing this. I definitly need your thoughts on this one.

[kryton9]

Oops, was just reading through tbgl help, see there are viewport commands :)

I will try to develop something this route as the program will all be in thinBasic then and easily modified by all users to meet their needs.

[holomind]

glut might be your friend, "glutCreateSubWindow"
http://www-etud.iro.umontreal.ca/~clavetsi/api/glut/glutCreateSubWindow.html

or this one
http://www.codeguru.com/cpp/g-m/opengl/article.php/c5583/

[Petr Schreiber]

Hi,

I think the viewports could do the job.

Thanks for the help Holomind, the second link looks good.
Regarding the GLUT - it is interesting library ( I learned big part of OpenGL when using it ), but the callback based engine is not very natural for me.
I am using it in my school project and it is not very happy work.

The window as a control is on the wishlist with high priority, but to be fair it won't be ready sooner than this summer. The same applies for the bone system, so not sure if we should hurry now. Maybe better to wait once those features will be implemented?

I would love to see this project progress soon, but as it is will be quite a opus magnus, better to go in little, sure steps.


Thanks,
Petr

[kryton9]

@Holomind, thanks for the links. I have used GLUT and for quick things it is nice I think. There is also an opensource version that is udated now.

The c++ app I started is being done as in your second link. But I know c++ is not a favorite of many (including me).


@Petr
I will experiment with viewport commands just to at least get a model viewer only and none of the other features.

Summer is almost here and before you know it FALL will be here, so no problem waiting for the cool features that will be coming Petr.
Nice to know they are in the works :)

[kryton9]

Petr can we have different background colors for each viewport.

I am trying the following and having no luck.

TBGL_BackColor( 0, 0, 255 )
TBGL_ClearFrame ( %TBGL_CLEAR_COLOR or %TBGL_RESET_MATRIX )
'tbgl_ResetMatrix
TBGL_Viewport 0,0.875,1,0.125
TBGL_Camera 1,1,1,0,0,0

It makes all the backgrounds the last color I specify with backcolor overwriting all earlier ones.
Thanks

[Petr Schreiber]

Hi Kent,

you are right. To clear the viewport background you could use a color cube, like in the following example:



Uses "TBGL"

' -- Create and show window
Dim hWnd As Dword = TBGL_CreateWindowEx("Viewports- press ESC to quit", 640, 480, 32, %TBGL_WS_WINDOWED or %TBGL_WS_CLOSEBOX)
TBGL_ShowWindow

TBGL_UseLighting %TRUE
TBGL_UseLightSource %GL_LIGHT0, %TRUE

tbgl_SetLightParameter %GL_LIGHT0, %TBGL_LIGHT_POSITION, 15, 10, 15, 1

DIM FrameRate AS DOUBLE

' -- Resets status of all keys
TBGL_GetAsyncKeyState(-1)

' -- Main loop
While TBGL_IsWindow(hWnd)
FrameRate = TBGL_GetFrameRate

TBGL_ClearFrame


tbgl_ViewPort 0, 0, 0.5, 0.5
TBGL_Camera 15, 15, 15, 0, 0, 0
TBGL_Color 128, 0, 0
TBGL_Box 1, 1, 5
DrawBackColor(128,0,0)

TBGL_ClearFrame (%TBGL_RESET_MATRIX or %TBGL_CLEAR_DEPTH )

tbgl_ViewPort 0.5, 0.5, 0.5, 0.5

TBGL_Camera 15, 15, 15, 0, 0, 0
TBGL_Color 0, 128, 0
TBGL_Box 1, 2, 3
DrawBackColor(0,128,0)

TBGL_DrawFrame

' -- ESCAPE key to exit application
If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then Exit While

Wend

TBGL_DestroyWindow

sub DrawBackColor( r as byte, g as byte, b as byte )
tbgl_ResetMatrix
tbgl_UseLighting %FALSE
tbgl_color r, g, b
tbgl_Box 100,100,100
tbgl_color 255, 255, 255
tbgl_UseLighting %TRUE
end sub


One note - if you specify viewport with proportions different than parent window, the rendered image is stretched.

For one 3D window and 2D overlay we don't need any viewports at all, see here:



Uses "TBGL"

' -- Create and show window
Dim hWnd As Dword = TBGL_CreateWindowEx("Editor concept - press ESC to quit", 640, 480, 32, %TBGL_WS_WINDOWED or %TBGL_WS_CLOSEBOX)
TBGL_ShowWindow

TBGL_UseLighting %TRUE
TBGL_UseLightSource %GL_LIGHT0, %TRUE

tbgl_SetLightParameter %GL_LIGHT0, %TBGL_LIGHT_POSITION, 15, 10, 15, 1

DIM FrameRate AS DOUBLE

' -- Resets status of all keys
TBGL_GetAsyncKeyState(-1)

' -- Main loop
While TBGL_IsWindow(hWnd)
FrameRate = TBGL_GetFrameRate

TBGL_ClearFrame
' -- Main scene
tbgl_RenderMatrix3D

TBGL_Camera 15, 15, 15, 0, 0, 0
TBGL_Color 255, 128, 0
tbgl_Rotate gettickcount/100,0,1,0
TBGL_Box 1, 1, 5

' -- 2D overlay
tbgl_RenderMatrix2D

TBGL_USELIGHTING %FALSE
TBGL_USEDEPTH %FALSE

tbgl_BeginPoly %GL_QUADS
' -- "Dialog Backround"
TBGL_Color 128, 128, 128
tbgl_Vertex 0, 0
tbgl_Vertex 640, 0
tbgl_Vertex 640, 100
tbgl_Vertex 0, 100

TBGL_ENDPOLY

DrawButton(10, 10, 60, 15)
DrawButton(10, 30, 60, 15)
DrawButton(10, 50, 60, 15)
DrawButton(10, 70, 60, 15)

TBGL_USEDEPTH %TRUE
TBGL_USELIGHTING %TRUE

TBGL_DrawFrame

' -- ESCAPE key to exit application
If TBGL_GetWindowKeyState(hWnd, %VK_ESCAPE) Then Exit While

Wend

TBGL_DestroyWindow

sub DrawButton( x as long, y as long, width as long, height as long )

tbgl_BeginPoly %GL_QUADS
TBGL_Color 255, 128, 0

tbgl_Vertex x, y
tbgl_Vertex x+width, y
tbgl_Vertex x+width, y+height
tbgl_Vertex x, y+height
TBGL_ENDPOLY

end sub



Thanks,
Petr

P.S. I will try to find solution for viewport image stretching, that is quite unwanted "feature". I think TBGL_RenderMatrix3D/2D should take current viewport size in consideration, I will change them to work this way.
So TBGL_Viewport + TBGL_ResetMatrix3D will be solution for the problem :)

[kryton9]

:)Thanks Petr for examples.

In the meantime I felt like dr frankenstein in putting your viewport and ui demo together into one.
It is not working right in that I don't see the viewports.

Can you take a look. I have 4 viewports still, but will get rid of them once can figure out why it is
not showing behiind the ui stuff. Also the text is not showing up on the buttons.

Maybe your fresh and also smart eyes can find what has eluded me in this long night :)

[Petr Schreiber]

Hi Kent,

just put "tbgl_renderMatrix3d" after WHILE.
You set 2D matrix somewhere and do not restore back to 3 dimensions.

But even if you will do this, the viewport views will look strange, objects flat or thin.
If there something strange in your neighbourhood, who you gonna call?

Well, for example ... me :D, I have sent new TBGL to Eros. That fixes the odd look and as a bonus it adds possiblity to define own coordinate system for 2D.

Stay tuned!


Petr

P.S. Added preview look with new DLL

[holomind]

perhaps you need gluperspective to repair the "stretch" of the image:

http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=42


// Set The Viewport To The Bottom Left. It Will Take Up Half The Screen Width And Height
glViewport (0, 0, window_width/2, window_height/2);
glMatrixMode (GL_PROJECTION); // Select The Projection Matrix
glLoadIdentity (); // Reset The Projection Matrix
// Set Up Perspective Mode To Fit 1/4 The Screen (Size Of A Viewport)
gluPerspective( 45.0, (GLfloat)(width)/(GLfloat)(height), 0.1f, 500.0 );


and some details about perspective and glFrustrum (redbook)
http://cs-sdl.sourceforge.net/index.php/Red_Book_Chapter_03#Projection_Transformations

[Petr Schreiber]

Hi Holomind,

you are 100% correct! Problem was that in current TBGL the width and height was took from window size, not viewport.
Corrected version has this fixed and working, in next thinBASIC preview you will find the fix + 2 samples.


Thanks again,
Petr

[ErosOlmi]

I'm preparing a quick thinBasic preview 1.6.0.7 in order to include new TBGL.
Ready by this evening max (CET time)

Eros

[Petr Schreiber]

Thanks Eros,

you were faster than I expected :)

Here is version working correctly ( see attachement )
requieres latest preview

Thanks,
Petr

[kryton9]

Thanks Petr. Who you gonna call-- CodeBusters.

Nice to wake up and have a working framework to start with!!

Thanks again.

[kryton9]

Petr the text is not working in the last zip. I was checking it with the working ui demo and am at a loss. Sorry, as you can see I lost my programming powers with the time off doing catch work with other things. I am at this type of loss in 3D too. It will take me time to get back up to shape:)

[Petr Schreiber]

Hi Kent,

no worries :) The text did not worked even in the first version you posted, I thought you remmed it out.
I will check it now.


Petr

[Petr Schreiber]

Found it,

just little problem, you tried to build font before the TBGL window was created, now it works :)
I also removed dependancy on UI module.


Thanks,
Petr

[kryton9]

Thanks Petr.

Actually that would make for some nice new tbgl ui commands:)

Will look at the new file now and try to soak it in. Thanks agian!!

[Petr Schreiber]

Actually that would make for some nice new tbgl ui commands:)

I know, I know :)

New file is not much different, I just shifted part of code with UI_Init after TBGL_ShowWindow


Petr

[kryton9]

Thanks having fun working on it while I redo my gaming computer (My HP Desktop).

The HP comes with restore dvd's only and no separate XP disk, so when you redo the system it installs of the crap ware that it is loaded with.

Today using these tools I was able to strip all the crap out and make my own restore images and my hard disk partitioned as I want.

1. Seagate Disk Tools - comes with seagate drives
2. Seagate Disk Wizard - this makes images of your drives and can make a boot disk
http://www.seagate.com/www/en-us/support/downloads/discwizard

3. This gets rid of all of the crap installed by manufacturers
http://www.pcdecrapifier.com/

4. XPLITE - this strips a lot of things out of windows for you
http://www.litepc.com/

I was able to make an image to my external usb hard drive.
I also made one on a partition on my hard drive.

All of this takes time, thank goodness for your help so I can keep coding while the computer works on the asis.

[kryton9]

Petr, I am getting this error see attached screenshot. I am trying to run the gl command to get the viewport width.

DECLARE SUB glGetIntegerv LIB "opengl32.dll" ALIAS "glGetIntegerv" (BYVAL pname AS GLenum, BYREF params() AS GLint)

How can I use this or can we have a tbgl viewport command to tell us the viewport width height and which is current under the mouse?
Not asking too much, I know it is but maybe something to put on the command list for the future :)

It might be simpler to just have one opengl screen and just render the ui separately, I will work on that now.
Thanks.

[kryton9]

Have to go to bed early tonight so didn't get as far as I had hoped, but at least a step forward.

I am thinking perhaps I need to understand and learn Mike's event manager to let it handle input events?
Need to study and think about it.

I think no need for viewports, just one window with the ui layer will work fine, at least for now.

[Petr Schreiber]

Hi Kent,

that rocks! Really nice look!

To get size of current viewport use:


DIM viewport(4) AS LONG
glGetIntegerV( %GL_VIEWPORT, viewport )

MSGBOX 0, "x:"+STR$(viewport(1))+$CRLF+ _
"y:"+STR$(viewport(2))+$CRLF+ _
"w:"+STR$(viewport(3))+$CRLF+ _
"h:"+STR$(viewport(4))


If we will not use viewports, the size of window inner area can be retrieved as:


TBGL_GetWindowClient( hWnd, width, height )


With the new TBGL update, we can take advantage of custom coordinate system. That means we can setup virtual reference system for UI stuff, which will be independent on resolution.

TBEM module is fantastic. You just define event types, attach them function "callbacks" and then just in the main loop use "TBEM_RUN" which is the core launching the functions in defined time.
Have a look at my clock example, it is kind of minimal sample what you can do with TBEM.


Thanks,
Petr

[kryton9]

Thanks Petr for the info.

While sleeping another idea, I know sleeping is dangerous. This one is simple gui editor for making gui :)

Maybe use entity system and simple text files that are output from the gui making wizard.
I will think about it while doing errands today and get a start on it when I get back.

I am trying to approach things in a more modular resusable way than before when working on projects.
Hope I can see the light while thinking about it :)

[Michael Hartlef]

Hi folks,

I'm doing good. Just was burned out from daily job and family. And I found out that doing something completely different in your offtime can recharge your batteries very well. Now I have to catch up with everything that was going on here.

Nice project!
Michael

[ErosOlmi]

Just was burned out from daily job and family. And I found out that doing something completely different in your offtime can recharge your batteries very well.
Own family: number 1 position always.
Very happy to see you again.
Ciao

[Petr Schreiber]

Hi Mike,

I am happy to see you here again :)

Bye,
Petr

[ErosOlmi]

I remember Michael was working on a project called thinPose. He created a User Interface under TBGL with menues and other stuff.
Maybe it can help for your project, Ken.

I was not able to find thinPose sources here in forum but, if needed, I have an old version.

Eros

[Michael Hartlef]

Here is the source. It is on development hold till Petr finishes the recoding of the animation part of TBGL.

[kryton9]

Glad you recharged your batteries Mike!

Thanks for thinPose zip!

[Petr Schreiber]

Kent,

I like how Mike has done the pull down menus, I think this is the way to go - looks nice and also not much different from classic menus like in thinAir, whic means less confusion to user.


Petr

[kryton9]

I can't believe all I forgot about coding in thinBasic while on the c++ trail...

Here is a test of a gui, very simple one, but I can see that this will be lots of work and you know me, it has to be easy..

I don't think I will go this route yet, but wanted to put the simple test up anyways to share.

[kryton9]

I think this is the route I would like to take, but since I will write it so it is modular and you guys can add to it. I thought I would share this sketch pad of an idea.
The basic idea is 3 windows.

First a pick dialog. This will select the major modes available.
Scene
M15s
Lights
Cameras
Events
and possible future ideas not thought of at the moment...

The second dialog area will actually show a dialog to give more controls for each pick item.
Right now there is just one dialog with a close button as a test.
But there will be as many of these dialogs as there are pick items.
Only the picked item will show its dialog.

The third window is the tbgl window showing the scene.

I figure this layout will give us the most modularity and possible path for future additions.
I wanted to get feedback and any ideas you guys might have before I go down this long road of coding on it.

I will make it a project file with each component in its own source code file.
This way once the initial stuff is done... Then Mike can work on the events for example. He will just make his dialog.
Petr can do the effects, oops another function to add :)
Well you get the idea.

The program really doesn't do anything at the moment. To exit, close the tbgl window or click on the close button or press good old escape while in the tbgl window(selected)

[Michael Hartlef]

Nice start. How do you wanna do the "modular" approach?

[kryton9]

I wanted to upload something before going to sleep to give a better approach.

As you can see, let's say Mike wants to work on events... he will work with the file events.inc
If there are any global variables that can effect other units, then it would be placed in the globals.inc.
Otherwise all code pertaining to the module will be in the units include file.

The mainapp calls the units as you can see from the first framework.

I hope this gives a better idea of how it might work and open it up to discussion to fine tune the initial steps to make it as modular as possible.

All the units are open to anyone who wants to tackle them.
So anyone who wants to join to the thinStudio fun should chime in as things are open.

You will want to load the project file, this will open all the files and the project select window makes it very easy in thinAir to go to differnt pages and routines.

[Petr Schreiber]

Hi Kent,

I like both your demos. The one with bitmap button looks nice, on other side it would mean to create multiple textures for buttons and controls which is quite a big amount of work.

So I like the dialog + TBGL window better.

I would prefer 1 dialog + TBGL window, as multi dialog proggies make me a bit nervous.
The "Scene", "M15s", ... buttons could be replaced with single combobox maybe. Its contents could be dynamically created based on INC files present. We could use thinLEV_<module>.inc way to make the modules easily recognisible. The functions inside could keep some SDK-like convention. Like <module>_Dialog( dialogHandle ), which would load control dialog ... controls :)

Then we could use CALL + dynamic string named functions calls to get the module functionalities.


Bye,
Petr

[Michael Hartlef]

Thanks Kent for the explanation. I will look into this after my daily job. I shouldn't be on the net right now. ;)

[kryton9]

Petr, I understand your point, but I used to program with one dialog window and then hide and show controls and it gets to be a task too.

The idea behind dialogs is making them for each task. I think we should try this route and if we run into problems fall back to one dialog.
The dialogs only work 1 at a time with the system I have in mind to eliminate confusion.
In early tests, there is no confusion so far in the system handling it.
I hadn't added the tests to see which is handled yet in the demo code.

I will add hide and show dialogs today to give a better picture. Also thought of many more future additions, so the pick window needs to allow for more buttons.
I will try vertical window to allow for many future buttons.
THe use of buttons is for quick access. If we use a combobox, too much work in selecting where you want to go, I didn't like that in 3DMax and that is why I like Blender, quick access to features via buttons.

Ideas that came during sleep:
1.- will make a wikispaces page for the program to keep it organized.
Link to here from there for forum discussions.
2.- the viewer editor will use the entity system
3.- I want to develop sprites or models for icons in the level to show lights, cameras, triggers and whatever else we come up with.

I will work on the revamp of the pick dialog today and getting the dialogs hidden and shown.
Then later tonight get a start on the wikispaces pages.

Glad you guys are excited by it too. Once the initial system is setup, then we can work on the parts we want and add it to the program, so it will be an easier task collaborating I hope.

[kryton9]

Here is an update to more reflect the design.
Now only one dialog at a time is shown and handled in the loop.
Also went to a vertical pick dialog theme. This will allow many more future options including a quick access via a list box to any object in a scene.

This leads to the next big decision, how to handle the data - via dictionary or linked lists. I will refer to either type as database for now.
Maybe in separate ways both?

It will be nice to have one database that lists everything in a scene, including the scene itself. This includes all lights, cameras, triggers, their icons, just anything that is in the level will be in a sorted list in a list view. This way it will allow direct and quick access to any item by the user.
I am not sure which of the above is the best to use for something like this.

It will be nice to be able to sort the data and display it in different ways depending on what situation pops up and also to allow modules to know what is available outside of its scope, this could be important for parent child relationship setups for example.

Anyways here is the latest, click on a pick button, the dialog for it appears and as you see, the close box on all the dialogs work, so no confusion in the system as to what called what :)

Oh I forgot to mention before... the project files are looking for the files at : C:\thinBasic\UserScripts\tbLEV
If you extract the rar into C:\thinBasic\UserScripts\, it will create the tbLEV folder and files so you end up with
C:\thinBasic\UserScripts\tbLEV\files*.*
and it should load up fine then.

Just updated names of files, got rid of the numbers.

[kryton9]

Charles, we could use your expertise in asm for procedural textures with your new modules too and primitive model generation to landscapes.

It will be great to use all the new features in thinBasic on this project to test them all out and to tap into the power they afford us.

Here are more ideas for modules:
project - this will manage the whole project and deal with scenes and transitions
scene - this will contain all info about a level or scene
m15s - for loading and transforming models
textures - texture module to handle all loaded textures and how they might be positioned on models (procedural textures could be here or separate)
lights - adjusting and adding more lights
cameras - adjusting and adding cameras
events - this could be split into smaller modules, not sure about how it will all work.
effects - this too could be split into separate modules as in 3d apps. Particles. Fluids. Cloth. Hair
sounds - this would be the sound manager for sound effects and anything non musical
music - this would be the scores and music in the project
splash - handle setting up splash screens with different effects
hud - design various HUD systems to appear on the screen if needed.
text - this would be where text items will be created and managed
primitives - add procedurally created models
backgrounds - manage skybox, skydome, ground and side planes. Or simple background color or use procedural backgrounds, like stars and nebula
volumefx - this could handle fog and other volume effects
physics - dynamic physic designer
help - this would be the actual help for the program.
about - about the crew

Please add any more you can come up with. I thought I had it covered last night and realized all I forgot about. I am sure there are still many things missing in planning.

[Michael Hartlef]

Kent, when you use the term modules, do you mean thinBASIC modules or something else? If you mean thinBasic modules, created with the SDK then I have to burst your bubble because they can't communicate with each other.

[kryton9]

Mike, no I meant the code written in thinBasic in the separate include files in the project.
I think we have enough powerful tools now in thinBasic to do something complicated as this.

It will be a good test to stress out the system and just make it better if anything crops up.

[Petr Schreiber]

Hi Kent,

good work. Looks monumental, but I am sure we will put it together.
It would be nice to use all available UI magic like treeviews and listviews.



Kent, when you use the term modules, do you mean thinBASIC modules or something else? If you mean thinBasic modules, created with the SDK then I have to burst your bubble because they can't communicate with each other.

I think they could. CreateFileMapping, MapViewOfFile, OpenFileMapping ... they could serve. I did experiments with thinBASIC and other (both compiled and interpreted) languages to talk together this way. I will post sample in two weeks.


Petr

P.S. The physics layer sounds good, although not sure for what to go. ODE is not bad, but it requires callbacks for comfortable collision detection. It can be done otherwise too, but it is not very pleasant way.

[kryton9]

For now I just wanted to throw out ideas and get input on possible things to or could be added.

I think the test shows so far that thinBasic can handle the 3 windows just fine and that code can be broken up and setup as a project very well now.

I am tuning and breaking things into separate files every time I get on. With the tree window in thinAir it is very easy to go to any page or function.

I will develop the m15 module as a model viewer, that will allow different models to be loaded and transformed for now and sort of see about setting up
parenting using entities after that. I guess it will be the logical step since the framework seems to work for now.

What about materials as opposed to just textures? Do we have the ability to make materials via layering different textures? Should that be a separate module too?

[Petr Schreiber]

What about materials as opposed to just textures? Do we have the ability to make materials via layering different textures? Should that be a separate module too?


Multitexturing? Generally in thinBASIC & OpenGL headers yes (http://community.thinbasic.com/index.php?topic=1043.msg6926#msg6926), but m15 models are single texture ones. They could be multitextured via hack I do not want people to get used to for now.


Petr

[kryton9]

Thanks Petr and thanks for the link... during restore of OS I lost all my old thinBasic stuff so have been downloading from the forums as I remember. Downloaded the linked downloads too.

[kryton9]

Petr, when a tbgl window is created does it automatically create one light and a camera? If so, what are their properties or how can I get them, any id's given to them?
I am working on the initial startup of tbLEV and want to put them if they exist. Thanks.

[Petr Schreiber]

Hi Kent,

no entities / objects / geometry / lights enabled in TBGL by default.
TBGL window creation just enables few states I find useful ( like depth testing :)), preallocates space for display lists and textures, sets correct perspective.

There is nothing like camera object in OpenGL in fact. But TBGL entities allow to define them ;D.


Thanks,
Petr

[kryton9]

Ok thanks Petr. I guess when the user creates a light, it must turn off whatever opengl uses by default then.

[Petr Schreiber]

I am not sure I understand you Kent,

are you talking about OpenGL, classic TBGL or TBGL/Entity light now :) ?

I recommend using TBGL/Entity lights for this project.
Entity lights use %GL_LIGHT1, %GL_LIGHT2, %GL_LIGHT3, %GL_LIGHT4, %GL_LIGHT5, %GL_LIGHT6, %GL_LIGHT7 as resource, %GL_LIGHT0 is reserved for special direct OpenGL use when needed.

Entity lights determine on their own which of %GL_LIGHTn they use. You can define any number of entity lights, but keep enabled just 7, if more is enabled only first 7 lights take effect and rest is ignored. If you need more light sources use technique I demonstrated looong time ago, with multiple TBGL_Scenes, each with 7 lights. Or we could go for multipass render of one scene.

OpenGL/TBGL does not use any light until you say you want one. By default there is no light lighting/active.


Petr

[kryton9]

I will be using the entity system, Petr that is for sure. I guess as I do each step it will be clearer. Thanks.

[kryton9]

Guys attached is the version that is the end of what I started earlier.
I figure if someone is doing a non entity based project this might be a useful framework to use or to start with.
Just load the project file and run or look through the code via the thinAir browser (F2)
It is not really functional in terms of doing anything useful, but the parts are there.

I can see that this version is not going to put me where I want with this project, so I will reiterate the process and hope to make it
more like what I envision in my mind's eye.

[kryton9]

@Petr, can I assign or set tbem functions, events or triggers with TBGL_EntitySetUserData?

@Mike, what would be a good way to visualize the difference between an event and a trigger the way you thought of it with tbem module when you designed it?

Thanks guys, trying to understand these modules as well as possible to make the most of them in the next version.

[Michael Hartlef]

Hi Kent,

mmmh, a good way to visualize triggers and events? Ok, let’s try this.

You (the flow of code) are in a production hall. Therer are different machines (events) to do specific different jobs. Your job is it to activate the machines (events) when needed. You can activate machines via press a button (fire a trigger). There are different buttons (trigger types). They are only activating the machines that are connected to them (via the trigger type). And only if they are connected to the power supply (event is activate or not). But the machines don’t run right away. You have to set the whole machine park under electricity via pressing the specific run button (runEvents) on your super duper control panel. Sometimes you have to press several run-buttons, as some machines are connect to one run-button (Event groups), the others to another one.

Sometimes machines run permanently, sometimes only for a specific amount of time. They also can reactivate themselves with a build in timer (Intervals).


Michael

[Petr Schreiber]

Kent,

TBGL_EntitySetUserData / TBGL_EntityGetUserDataPointer ( now I realize the name is a bit long :) ) serve just to assign or read UDT structure to/from entity. You can store the trigger IDs, function names or other properties there for example, but this command does not cause execution of other ones.

Mike, nice explanation of triggers!


Petr

[kryton9]

@Mike, thanks for the very nice visual description of the event module. I want to figure out this monsterly powerful machine that is for sure!

@Petr, great news in that I can store the things needed for events with entities but set and manage them via the event manager.
I guess the way you and Mike set that up it goes both ways as both modules provide this power of storing udt or other type data and being able to set and get that data.

Thanks for the info guys!