Quote: "I also can't see how it would be possible to make OOP optional. It didn't work out for C++ (it didn't take very long before everyone started spamming his object oriented garbage all over the place), why would it work out for any other language? "
It didn't work out because many have chosen to use OOP or because they're forced to use OOP? Check out Dark GDK, check out its samples, not a single class, no OOP, all procedural. Dark GDK is designed to favour procedural, but doesn't make OOP impossible for those who wish to use it.
For example here is (from the samples folder):
// Dark GDK - The Game Creators - www.thegamecreators.com
// include Dark GDK header file
#include "DarkGDK.h"
// global variables - used for the camera
float g_fSpeed = 0.1f; // speed at which camera moves
float g_fTurn = 0.03f; // turn speed for mouse look
float g_fOldCamAngleX = 0.0f; // to store original x angle
float g_fOldCamAngleY = 0.0f; // to store original y angle
float g_fCameraAngleX = 0.0f; // to sotre new x angle
float g_fCameraAngleY = 0.0f; // to store new y angle
// forward declaration for functions
void userInput ( void ); // handles user input
void showFPS ( void ); // show frame rate
void DarkGDK ( void )
{
// entry point for the application
dbSetDir ( "media\\" );
// initial application set up
dbSyncOn ( ); // turn sync on
dbSyncRate ( 60 ); // set sync rate to 60
dbBackdropOff ( ); // switch backdrop off - no need to clear screen
dbSetCameraRange ( 0.5f, 30000 ); // set the camera range
// load images for the terrain
dbLoadImage ( "media\\texture.jpg", 1 ); // diffuse texture
dbLoadImage ( "media\\detail.jpg", 2 ); // detail texture
// create the terrain
dbSetupTerrain ( ); // set up terrain library
dbMakeObjectTerrain ( 1 ); // make a new terrain
dbSetTerrainHeightMap ( 1, "media\\map.bmp" ); // set the terrain height map
dbSetTerrainScale ( 1, 3, 0.6f, 3 ); // set the scale
dbSetTerrainSplit ( 1, 16 ); // set the split value
dbSetTerrainTiling ( 1, 4 ); // set the detail tiling
dbSetTerrainLight ( 1, 1.0f, -0.25f, 0.0f, 1, 1, 0.78f, 0.5f ); // set the light
dbSetTerrainTexture ( 1, 1, 2 ); // set the textures
dbBuildTerrain ( 1 ); // build the terrain
// create our skybox
dbLoadObject ( "media\\skybox2.x", 200 ); // load the skybox model
dbSetObjectLight ( 200, 0 ); // turn lighting off
dbSetObjectTexture ( 200, 3, 1 ); // set texture properties
dbPositionObject ( 200, 1000, 2000, 4000 ); // position the skybox
dbScaleObject ( 200, 30000, 30000, 30000 ); // and finally scale
// set starting camera position
dbPositionCamera ( 385, 23, 100 );
// loop round until escape key is pressed
while ( LoopGDK ( ) )
{
if ( dbEscapeKey ( ) )
return;
// show the frame rate and handle user input
showFPS ( );
userInput ( );
// update the terrain
dbUpdateTerrain ( );
// render everything
dbSync ( );
}
}
void showFPS ( void )
{
char szFPS [ 256 ] = "";
strcpy ( szFPS, "fps = " );
strcat ( szFPS, dbStr ( dbScreenFPS ( ) ) );
dbText ( dbScreenWidth ( ) - 20 - dbTextWidth ( szFPS ), dbScreenHeight ( ) - 40, szFPS );
}
void userInput ( void )
{
dbControlCameraUsingArrowKeys ( 0, g_fSpeed, g_fTurn );
g_fOldCamAngleY = g_fCameraAngleY;
g_fOldCamAngleX = g_fCameraAngleX;
g_fCameraAngleY = dbWrapValue ( g_fCameraAngleY + dbMouseMoveX ( ) * 0.4f );
g_fCameraAngleX = dbWrapValue ( g_fCameraAngleX + dbMouseMoveY ( ) * 0.4f );
dbYRotateCamera ( dbCurveAngle ( g_fCameraAngleY, g_fOldCamAngleY, 24 ) );
dbXRotateCamera ( dbCurveAngle ( g_fCameraAngleX, g_fOldCamAngleX, 24 ) );
char* szKey = dbInKey ( );
if ( strcmp ( szKey, "+" ) == 0 )
{
if ( g_fSpeed < 1000 )
g_fSpeed = g_fSpeed + 0.01f;
}
if ( strcmp ( szKey, "-" ) == 0 )
{
if ( g_fSpeed > 0.02f )
g_fSpeed = g_fSpeed - 0.01f;
}
float fHeight = dbGetTerrainGroundHeight ( 1, dbCameraPositionX ( ), dbCameraPositionZ ( ) );
dbPositionCamera ( dbCameraPositionX ( ), fHeight + 3.0f, dbCameraPositionZ ( ) );
}Quote: "OOP deserves to be purged not only from every curriculum worldwide but game development and the industry as a whole. It isn't efficient and it pretty much ruins every language I ever loved (including the original C). "
That's up to the programmers. If you're able to use procedural and you prefer the method, I am not exactly sure how it ruins your favourite languages, because last time I check C++ doesn't force you into OOP. There are libraries that do (like Irrlicht), but you can't exactly dictate how other programmers choose to program.
Talking of inefficiency, Dark Basic Pro is in itself inefficient, it is designed for ease of use. But people use it and even create professional products from it. Interestingly, using an Irrlicht wrapper inside of DBP is more efficient than using DBP SDK as we've found by testing it, that it's faster (I've not found by much, maybe, 10,15fps in the example, but WLGfx has found he's got a 25% increase). Irrlicht is OOP, Dark Basic Pro SDK is procedural. All those OOP commands are wrapped up inside of the DLL. It's possible that Irrlicht would be more efficient if procedural, I do not know, but what I do know is that DBP isn't as efficient as it should be, but it provides plenty of use to the user, which at the end of the day is what it's designed for. IMO, OOP would add to that.
Quote: "If you want something to be flexible, efficient and futureproof, you better go with procedural/functional and proper support for inline ASM (which I sorely miss. IMHO, they should add it to Dark Basic Elite)"
If there's a demand for it, why not? At the end of the day, TGC will probably implement features that are in demand and that are worth their time adding. If enough people want OOP, I'm sure they'll consider OOP. Same for Inline ASM. Perhaps you could cook up to made up code to show us how it might work inside of DBP. Who knows, somebody else might think it's a good idea?
Quote: "
I can't imagine the mess needed to replicate this class(just the header file):+ Code Snippet
and have all the variations and specializations that I require for my game(NPCs, enemies, etc) without an huge explosion in the number of lines of source code and the repetition of particular parts of the code."
Agreed. The main use I personally find for OOP is the fact classes are replicatable and are able to contain plenty of data. I used UDTs in Dark Basic Pro to help manage my code in a similar way, but I would see it working better if there were classes too. In essence a UDT is a class without the ability to use functions inside, so a part of the functionality of a class already exists in DBP.
Quote: " For instant 'player.inventory[0]' which would access the first item in the player's inventory. In non-OOP you would have to have these as unrelated values which you have to link yourself which gets more complicated once there are multiple objects, each with their own inventory. In OOP, not a problem."
I found my inventory system has been vastly improved using OOP, or heck, UDTs in DBP. If you wanted each item to have an attribute, in procedural you'd be doing:
dim ItemID()
dim ItemName()
dim ItemCount()
dim ItemDescription()
...
Whilst it'd work. I find it's tidier to stick them into a class. I can then declare it for an Enemy class, or a player class or even a room class. Using an array in the above method, sure I could have it 2 dimensional, so the first number denotes say, a player or an enemy and the second number is the slot, but I think in terms of coding that'd be inefficient because you'd have to go back and adjust the size of the array everytime you add something new and when you consider you might have 5 different characters and a 100 different enemies and 40 different rooms, it could start getting messy. Whilst it's not impossible to manage in procedural, OOP deals with this in a much better way IMO. I see nothing wrong with making life easier for the programmer or offering them quicker methods, because it means for one thing, they're being more efficient, whilst the code might not be as efficient, but then, we sacrifice efficiency for ease & speed of use anyway. It's the whole reason higher level languages exist. However, to the end user, this isn't exactly noticeable.
A coder at the end of the day will use their preferred method.
Quote: " And don't replace Dim with Type. I like Dim."
It won't. DBP already has types and it hasn't replaced dim, it just can be declared using dim. What's being asked is for TGC to add to Dark Basic, not to take away. Heck, adding functions to types would be all that's needed to satisfy anybody who wants to use OOP. The functionality is almost there.
