[TynesideLUG] C++ Links

[Casey Earnshaw]

Hi Ian

Thank you for the link to asking more pertinent questions. I have taken 
its advice to heart and I will try to be more concise and seek other 
sources more thoroughly before asking questions in future. I realise 
some mistakes I have made and I wish to apologise and I will try to do 
better next time. I have registered a stack overflow account and I will 
start using that before emailing the ACCU list in future. Not that this 
is an excuse but last night I had been trying to get visual studio code 
to compile a mix of c++ and c files for a few hours and I was quite 
stressed out and starting to blame the tools. I think that's why I came 
over quite wishy washy because part of me wanted to throw visual studio 
code in the bin and try something else. I had spent some time searching 
the internet and trying to read the man page, but GCC is a very 
intimidating tool for a beginner; I've never seen a program with quite 
so many options before.

I've only been using C++ for about a week and its been challenging to 
get to grips with the way C++ does things. I find myself in a bit of a 
tough spot finding relevant information on the internet because so much 
is written about it in many different places and finding an entry point 
is challenging for someone who is new to the tool chain but is beyond 
Hello World!. Building just feels needlessly complicated to me at this 
stage. When using godot engine or C# you click one button and your app 
opens. It may be that those languages do compile, build and link but its 
all abstracted away to just one button press. I can learn the C/C++ way 
and I will get used to it eventually, it was my own stupidity that was 
stopping step through and break points to work which are features I've 
probably grown far too reliant on using the friendlier languages. But 
they seem to be working now so I can continue that habit. I need to 
learn to sit on questions for a little longer in future though, 
sometimes a nights sleep can help more than reading the same out of date 
website for the 5th time.


_Why  I want to use SQLite over POD:_

A small snapshot of our data design structure is as follows:

We have cities that have locations in them.
We have people who live at those locations, often with family members, 
and work at other locations, they also go to amenities that the city has 
outside of their work hours.
Each person has one or many devices and multiple friends.
Each location has a phone line and a persons device is set to connect to 
the router connected to the phone line of the location that it is in. 
Mobile devices move around, workstations stay in one place.
Each device has a file system with additional files in it.

We want our game to support upwards of ~10,000 people per city and you 
get as many cities as you have CPU cores at the moment.

The main motivation for wanting to use a database is that this data is 
relational and my thinking was that with it being relational a database 
is probably more optimised for handling that kind of data structure. 
Also using a database allows us to use serialisation. (I've not tried 
storing serialised data in json before but I'm uncomfortable with 
storing non printing bytes in plain text, maybe it would work, but it 
seems to be asking for trouble).

We have used 2shadys SQLite plugin but we have only used it in cache 
mode and as such the memory footprint of the game was much larger than I 
felt comfortable with, especially as we end up holding onto data of 
people that the player would never reasonably access in a single play 
session. We do want to be able to support the player poking into random 
systems at their discretion and not be limited to only being able to 
interact with the people related to whatever mission they have accepted 
so everything does need to be available. I just don't want it sat in the 
ram all day.


_Tool chain nightmare_

The other issue is Godot 4 recently came out (Thursday) and it has 
breaking changes as such that the plugin doesn't work any more and 
2Shady's plug in has garbage performance when using it to create a flat 
file database and we believe we can do it better. Browsing their source 
code...yeah we can do better for our specific domain.

I have experimented with using JSON files and relying on the gdscript 
equivalent of fopen. This has worked but its more complicated than using 
SQL statements to access the data. Also: 
https://www.sqlite.org/fasterthanfs.html

We are currently using a mix of C# and GD script with most of the game 
written in the latter. Now, writing plug-ins we are adding C++ to the 
code base as well and I can imagine eventually optimising other parts of 
the game in C++ as well. The godot engine has a text editor built into 
it which allows you to breakpoint and step though GD script.

When I mentioned "debugging" in the previous email what I really meant 
was the ability to things like breakpoints/step though or something 
similar rather than anything specific about bug fixing. I wasn't even 
sure if you COULD do the above with C++; C# and GD scripts are both 
technically interpreted whereas if I am understanding it correctly, C++ 
converts into assembly and my assumption was because of that the 
original source file "lost"? Apparently not it turns out because I have 
managed to get breakpoints and step though working now. Reading it back 
now I realise how unspecific and open ended a statement that was and I'm 
sorry.


Perhaps I need to take a little bit of a break. I've been coding pretty 
much every day non stop this year and perhaps I need some time to 
reflect. I feel that I have made a lot of progress though. Bear in mind 
that I hadn't touched C# until the start of this year and I was always 
too intimidated by C and C++ so I'm proud of the fact I'm giving them a 
go but they do seem a lot more complex.

Anyway, I hope you have a better understanding at where we are at at the 
moment.

Regards


Casey



On 06/03/2023 21:57, Ian Bruntlett wrote:
> Hi Casey,
>
> On Mon, 6 Mar 2023 at 21:02, Casey Earnshaw<casey at linuxmail.org>  wrote:
>
>> Thank you very much for the links. I've been doing some C++ today and
>> trying to get the SQLite plug-in to work. Progress is very slow though
>> because we kind of have to treat it as a black box then compile it over
>> to the Godot engine and see if the engine can handle it. I don't know
>> enough yet to debug efficiently and I was wondering if maybe you could
>> give us some advice?
>>
> One way of getting the most benefit out of asking questions on forums and
> email mailing lists is to read this article:-
> http://www.catb.org/~esr/faqs/smart-questions.html
>
> Being able to narrow down the scope of a question to actual specific points
> will encourage people on mailing lists/forums to answer your questions (I'm
> thinking of accu-general in particular).
>
> Do you have a data design/structure? If so, look at it and consider
> "Couldn't I just read this all into some vectors of PODs ("Plain Old Data
> Structures", aka structs in C++,). Having a good idea of the data you're
> going to handle will help you in the long run. It might even be practical
> to store your data in simple text files and read the data into GDScript (
> as done in this example:
> https://godotengine.org/qa/57130/how-to-import-and-read-text  ) stored in an
> array or other container object or even in C# if you prefer that.
>
> The difference in intent to using the struct keyword and the class keyword
> is that by using a struct you intend to have plain old data that does not
> have a "class invariant" associated with it. In C++ the keywords struct and
> class have almost identical meaning.
>
> I know next to nothing about the Godot engine (
> https://godotengine.org/features/  ). It looks interesting and GDScript has
> the advantage of being the "native tongue" of Godot. I did find something
> about debugging GDScripts (
> https://docs.godotengine.org/en/stable/tutorials/scripting/debug/overview_of_debugging_tools.html
> ).
>
> So, to recap:-
> 1. Read the smart questions FAQ I linked to.
> 2. Have a really good think about your data and how you intend to use it in
> the future.
> 3. Something to consider: Look at GDScript and see if you can access text
> files from it on your system.
> 4. Something else to consider: There appears to be an SQLite wrapper for
> Godot. Can you get it to work:https://github.com/2shady4u/godot-sqlite
>
> A lot really depends on what you want to get from your game project. Would
> you mind sharing that with me, so I can try to advise better?
>
> HTH,
>
>
> Ian
>