[WIP] AmiDARK Basic OS4 - Tech Demo BASIC 2D - Stars

@Samurai_Crow
In fact, at this moment, I don't want to link to external files simply because no one of the included files is in its final state.
All files can have changes to be made so I prefer include them at .c state and later when everything will be finalized, I'll compile and includes them as objects ..

@freddix

Quote:

Including .c files is really bad practise and you're going to get yourself into trouble soon, as the size of your project increases. Get into the habit of creating header files right away. Put the function prototypes and documentation for functions that should be used by other source files into the header file, and include the header file from your .c file of the same name (and any other .c file that needs it).

It doesn't matter if something is in it's final state or not; don't include .c files.

Also, learn what an Abstract Data Type (ADT) is. You're going to need it if you want to make anything but the smallest programs. That will also give you a good idea of what goes into a .c file, and what should go into a .h file.

Hans

@Hans
I have already (in other languages) made projects that take more than 50000 lines of code and doing includes of source code components without going into troubles ;)
I can't compiles and include them as objects because a change in a .c file can force me to do changes in another .c file ... so I don't want to spend time changing the .h and recompile separate files ... it's time losing ..
I'm "used" with working with several files for 1 project ... it's something I master easily :p

Of course, I'll check what you gave at advices to see if it's bette for my case ... but I doubt ...

Bye

@freddix

Quote:

If you often find that a change in one .c file causes changes in another, then you're not designing things in a modular enough fashion. That's why I suggest learning what an ADT is. By including .c files you are risking making a real mess of interdependent .c files.

Each .c file should be a single "module" that focuses on a particular task. A rough interface (API) to use that module should be designed before you start coding; this goes into the .h file. Naturally you will probably have to change the API a bit over time, but the goal is to design it in such a way that changes in the .c file are invisible to other .c files. By thinking about how other source-files will use a particular .c file beforehand, and putting that into the .h file, you eliminate/greatly-reduce having to edit multiple .c files for one change. If the API for a .c file is done right, you should be able to rewrite the.c file from scratch without it affecting the rest of the program.

If you use makefiles, then recompiling separate files isn't an issue at all.

Hans

@Hans
You're not totally right.
When designing a programing language using plugin system, you're right that each plugin own its own structures and command set however, the one that handle the display (and then opengl setup) must share informations with some other ones (sprites, images, basic 3D) because they are dependant on this one and, due to the fact that adding new command to one of these sets (like for example adding primitives 3D objects) will require to modify some opengl options and refresh, I must work using this method.

@freddix

Quote:

Actually, you don't need to work using that method at all. I have created a small 3D engine before, and I could modularize it pretty easily in such a way that sharing internal information between .c files is unnecessary. This isn't about using plugins or not, it's about de-coupling code so that there are no complex interdependencies.

What little information you actually need to share can be done via functions defined in the .h file. For example, a sprite would have a position, size, and a texture. It doesn't need to know anything about the size of the screen, etc. A single pointer to a render function could be defined in the sprite structure that takes care of all the OpenGL rendering stuff in order to draw it to screen.

The sprite would need a texture, which is something that should be put into another .c file. However, if the texture module has the following functions (with prototypes in texture.h):
- createTexture()
- deleteTexture()
- useTexture()
- endUseTexture()
- getTextureWidth()
- getTextureHeight()
- getTextureType()
then the sprite object doesn't need anything more than a pointer to a texture object in order to use a texture.

Now if the sprite has the following functions:
- createSprite()
- deleteSprite()
- renderSprite()
- getSpritePose() // obtains the x, y and angle coordinates
- setSpritePose()
then your rendering engine requires no knowledge about a sprite's internals at all. It can do everything it has to via these few functions.

The same applies to 2D/3D objects too. If all objects to be rendered have a pointer to a render function in their structure, then your graphics engine won't even need to know what kind of object it is rendering; it just does a; object->render() call.

I could go on, but it would probably be an overload of information. Learning how to isolate code so that changes in one file hardly ever affect another will take time. However, it is possible.

Hans

@freddix

Hallo Freddix, i've seen that the site of odyssey-creator doesn't "exists" anymore because company bought by thegamecreators.com.

But tell me, is the developpement of AmiDark is still in working ?

Thanks.

@unimon
Hi :)

In fact, I've only reselled the product I did develop under my label Odyssey-Creators to TheGameCreators to pay charges and taxes.
I was obliged to stop commercial activity (too much charges and taxes and not enough cash win).
I didn't reselled the label "Odyssey-Creators"

And, concerning Amiga Development, I do this for my pleasure so, "yes" AmiDark ENGINE is not canceled ;)
But it will be a bit slowed down because I must work a second product in parallell for PC computers
(because I have a credit to pay for the company I created even if the company failed :( ... so this other product will help me pay the credit)
The good thing in this is that this product will be integrated in the AmiDARK engine or as a separate product for AmiDARK engine ;)

Thank you for your support in my projects.
I will maybe release a new small demo soonly using 2D and showing the work in // with the PC product ;)

Bye.

@freddix

Thanks for the update, Freddix. I'm sorry to hear that you're in financial trouble but glad to hear about AmiDark continuing.