Code: Suggested "CORE" structure

[ISAWHIM]

######### UPDATED to GameCore-(V0.0.0.2)
- Fixed issue with "VSync", not accepting a variable as a value. {FIX: INT(value) was the solution to the change.}
- Added a temp-intro test, using another suggested game-name, as the test.
- Created and tested scene-swapping ability.
- Added a few notes.
- Added a few generic subs.
#########

I have created a generic "CORE", which I would like considered for acceptance towards the final format. I have created what I believe, is a good opening shell, for the progression of the complete game.

This "CORE", implies that we follow and stick to a single standard, which should hopefully speed-up development, and allow for easy integration and testing as progression takes place.

The main concern would be about individual code wanting to use similar values.

To open the floor to the first suggestion of a standard...

Many common shared values from the core, will/should hold to the same format as an include.

I propose that all includes, unless severely needed, not have any globals. Where a global is needed, I suggest that the creator of the include, ask for a unique "IncludeID", which will be a prefix to all include globals, and will also be a prefix to the include file. (EG, prefix = "i7C_", file would become, "i7C_MyInclude", Globals and constants would become "i7C_MyGlobalVal", "i7C_MyConstantVal".)

I also propose that all includes contain only functions and subs, and not any "Raw-code" outside of functions or subs, as that may interfere with the "Core" operation. This also requires that all SUBS and FUNCTIONS should be registered, so that no two functions in separate includes have the same name.

Beyond that, I have also created a suggestion for the opening level of FLOW, in the form of a generic standard set of universal entities, related to each of the potential uses.

See attached files.

Please, feel free to provide feedback, input, or suggest a change. This is only the opening level of generic development. But has more than enough for us to begin, up to the point of playing. (I am still using the SandBox3 for experimenting with play-elements.)

[Petr Schreiber]

Hi Jason,

thanks for your work

Just one thing - why would TBGL_UseVsync not work with variable?
Following works well for me.
[code=thinbasic]
dim flag as number = 1
tbgl_usevsync(flag)
[/code]
Also if you think you found a bug, do not do workarounds but simply report it. This is better to keep modules "healthy"


Petr

P.S. Cool intro

[ISAWHIM]

I didn't realize "Number" was a type...

I was trying Double, Long, Dword, Quad, Boolean, Byte... the "Number" variable types, as opposed to array() and string.

Change will be made... TY

[Petr Schreiber]

Well,

even double, long, byte ... everything works for me.
In which sense it did not worked for you - run time error or no effect?

In any case TBGL module parses the value using thinBasic_Parse1Number and then passes it BYVAL as LONG value to OpenGL... there is no way how it would cause problems.

I would like to have this fixes, I can say I like animals in general ... but not bugs


Petr

[kryton9]

I'm not in the coding team, but was wondering what %sACC stood for in the constants?

[ISAWHIM]

I will recreate the error, hopefully, and post that segment... (There is only one segment where it is used, in the initial setup, based on user-selection, possibly reset when the selection changes.)

The way I was thinking...
The %sACC, would be the accessory scene, for we are at a selecting screen for anything that is not a TRACK or a CRAFT. Tracks would have many objects to display the single track. But the craft selection would have all crafts loaded, for selection, but not have any accessories in it. The accessory scene would have only similar accessories loaded, but not ones of another type. EG, three engines, showing one at a time, or all three in a ring, for selection.

EG...
Engine selection (Renders the accessory engine model, not used in the game, but displayed for the selection.)
Weapon selection...
Game items/objects encountered...

Used for a generic and quickly disposable scene. (Would not use the same lights or cameras or other rendering options as other scenes.)

So...
When we are selecting our engine... The engine may be up in the top-right, while our craft is on the top-left, with engine info displayed below on the bottom. The craft would have its own display settings, as would the engine. As opposed to attempting to place each item in one full 3D scene, with separate lighting and cameras, that would normally have to constantly be arranged. We setup the "Display scene" once, and just swap components, hide/show as desired, move/slide them around in the GUI (Main), without altering the actual scene itself in the process.

On that same respect... When selecting the track, our selected craft may still be seen in an opposite corner. But that would have no relation to the game scene, (%sPLAYER).

When the select stage is finished, the scene is just dumped, freeing that memory for the game, or another GUI area, or kept, for fast loading of the last selected craft, track, and accessory. (With the many accessories, I imagine that a sub-selection screen would be needed, but each accessory-type would not require its own screen, as the track and craft would. The loading and display would be less demanding. Thinking that some of these accessories may be imposed onto the craft model, if we have time, at some point.)

The difference between the (%sPLAYER) and say... (%sTRACK)... the %sPLAYER contains the track, but also has the AI path, all other crafts, additional and specific cameras, paths, etc... While the %sTRACK would only contain the track and building blocks. Which we could also use to render as an in-game image to display a top-view player-locations as a PIP view. (As opposed to creating separate images for every track, or rendering two tracks at once.)

[kryton9]

I see thanks for the explanation Jason. Sounds good.

[ISAWHIM]

Ok, those all seem to work now... odd.

Not sure why I was getting errors. They kept saying "End of line", and pointing to the next line of code, but saying the error was the VSync value not being a valid type.

Could have been a COPY/PASTE issue, chr (10,10) not (10,13)...

Once I saved, closed, and reloaded, now the INT(value) can be removed.

I will have to shut-down TB more often after I crash a lot. (Seems that things are staying in memory on a crash, as opposed to when I do a normal exit. I don't crash often, unless I am playing with odd new code. At the moment, I was playing with the FOV code.)

I will revert that back again, in the next release.

The sky-box looks like it may be the first include to make it into the CORE. Followed by the ("FOV"-safe font-function) for the info-scene. Followed by the (safe "FOV"-function). LOL.

I am thinking about a resource loader function. (One that would load X,Y,Z resources, and return an array of assignment values to the calling code. Skipping loading of existing resources that are already loaded. Just returning those values in the array.) Specific ones for images, m15, sounds, and internal-objects?

EG, if I ask it to load "image2.bmp" from "\shipimages\", but another scene has loaded it, and is still using it... the value created for that image would be passed to the calling line, as well as a destroy code. Those same resources would be destroyed/unloaded by the same function... but not if another element is using it. (Eg, both destroy codes would have to come-in.) Not sure if that is even needed, but with the TRACK scene and the PLAYER (Game) scene... it would stop a lot of redundant loading.