Advertisement

Game engine in C and open source, The Box, structural programming

Started by December 22, 2019 10:49 AM
129 comments, last by alex4 4 years, 8 months ago

Graph App code, on draw pixels:

get_pixel(Point p)
{
return 0x00FFFFFF; /* cheat for now, return white */
}

set_pixel(Point p, unsigned long c)
{
enable_drawing();

set_rgb(c);
draw_point(gc, p);
}

draw_point(Point p)
{
draw_point(gc, p);
}

draw_line(Point p1, Point p2)
{
draw_line(gc, p1, p2);
}

The drawing of pixels is in functions, this is something that could slow down the performance by a lot. This functions is called “N” hundreds of time.

Instead if convert them in to loops, will be much faster, think i will create some kind of map or area of the pixels, so i can access them lather. To know what have been done. Maybe the “layer.h” i talk earlier and people probably din't understand will come in help now. We could put pixels in layers. width coordinates. red buttons on this screen → "100px right position" 3 buttons 80px by 80px. Etc…

#include draw.c
----
while(draw_pixels != null){
→draw
→create map
}
---

Definitely a good idea to cache the pixel/line arrays in between frames so you can re-use them so you don't need to call all those functions again. Just curious, how are you planning on actually outputting these to screen? Hope you're aware that different environments will have their own performance-related quirks. Modern OpenGL/DirectX, etc will want you to have these pre-cached as arrays in GPU memory. If you're drawing them with the CPU and then blitting them to screen somehow, be aware that you only get 33 milliseconds per frame or so, which is not a lot of time to do a whole lot of memset() calls. When can we see some graphical output?

Advertisement

@voxycdev
The develop take a lot of time, i'm doing all things procedural, still working a couple of hours per day.

Changes:

- thinking in doing a to do list, will be easy if any one want to do a task for the project.
- we now have a call back object (call_back.h) to create dynamic variables our functions.
tutorial on call back, or load of dynamic functions. Since all object file are non dynamic, we then will have a dynamic object to create instances.

https://www.tutorialspoint.com/callbacks-in-c

https://www.geeksforgeeks.org/callbacks-in-c/
-Graphics renamed to pixel.h, since we are drawing in pixels as the guy from voxy box mention we could be drawing in lights like holographic. Easy to add and remove things this way. like remove pixel.h and and holographic.h
- Found the explanation for the Bitmap drawing

“is preferable to draw the graphics on a bitmap residing in memory which can be rendered on a component whenever the a Paint() event is triggered. This avoids the problem of having to call all the Draw methods or store and replay a complex sequence of draw commands each time the graphics need to be refreshed.”

This will be connected to our pixel_map.h and layer.h. To handle this things.

- The libraries, arranged it a bit better. now the folder application structure deals only with the theme of the application main functionality.

Our the structure is looking like:

#include error.h

#include file.h

#include path.h

#include type.h // manage data types

#include position.h // x and y location

#include memory.h

#include database.h

#include image.h

#include bitmap.h // draw

#include model.h

#include cursor.h

#include keys.h

#include font.h

#include event.h

#include layer.h

#include pixel_map.h

#include window.h

#include control.h

#include graphics.h

#include 3D.h

#include 2D.h

#include draw.h

An engine coded in C that keeps everything on the hard drive and prefers global variables instead of function parameters.

I wonder why the rest of the industry doesn't design their engines this way lol

@Funkymunky Don't know try to design nested code, and read nested code. I prefer to know where all the stuff is. Your capability to program is also your capability to read the code. If does not have readability is close to un maintainable code.

Passing parameters to functions your mad? After 10 or 20 functions try to remember which variable is where. Is not readable.

@VoxycDev

I will be preparing version 0.0.3.

  • -Think that i want to have working images, Bit map
  • -The to do list, already mention
  • -Better manual, when i read it after publish 0.0.2 see a bit of repetitions there in the phrases/topics, din't have more time to fix it.
  • - Considering more forums, maybe will get more people, already in 3 places thinking in moving to a 4º development forum
  • - The Github, is a matter of a to do list, don't think github will do that much. It is a kind of replace of the to do list. "A bit of lasy"...
  • - Once the images are working we could have the interface working, and tools after.
  • - Some tools take time to finish and improve the details for example like the “game lore tool” left many stuff behind to do. I know that is not a working tool, but the planning have priority.
  • - Also the debug tools is something i want to do once start testing code. It will make the process more easy.
  • - After the interface i will dig a bit in to the 3D, want to do some costume things but that is probably a huge consuming of time. Better have some tools working before digging in to that.
  • - The first tool i want is the tutorial to have stuff organized them projects, so people can have their projects in their width the community because is online to help development and "costume game" tool for people who want to play retro costume games.

For know width the knowledge i have in C is the possible development.

Advertisement

My C++ engine isn't heavily nested and it's quite readable. I don't generally share variables between 10-20 functions, but i'd still prefer they be on the stack if I did. Global variables are a huge red flag of an inexperienced developer.

Funkymunky is maybe super smart and able to design his nested, well organized, modular codebase in a way so it is never necessary to have overview of the whole thing, but just that certain one he currently works on.

I guess having no globals is pretty helpful here, because tracking the state of 10 or 20 global variables is just as bad (or actually much worse) than passing parameters through the same number of functions. (But what do i know, because neither ever happened to me, thankfully.)

EDIT: Did not notice he did answer himself meanwhile, and i swear it is total coincidence we both gave the same answer.

If not using global variables, not storing everything to the harddrive, and preferring a language with built-in Object-Oriented support is “super smart”, then… sure?

Just… it's a billion dollar industry. If this was a good design, it would be what people implemented. If you're getting this much push-back, maybe you should stop to consider why. Even Carmack switched to C++ for the destructor, come on.

Funkymunky said:
“super smart”, then… sure?

I meant it ironic - agree with all you say.

This topic is closed to new replies.

Advertisement