Ma-Shell

October 23, 2021

I believe the one you need is the c_cpp_properties.json (https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference, https://code.visualstudio.com/docs/cpp/config-linux#_cc-configurations). There is an "includePath" setting there, which you will probably need to set correctly.

June 22, 2021

You can put everything into one line:

sudo apt install build-essential libx11-dev libxmu-dev libxft-dev libxcursor-dev

No need to retype the password if one of the installations takes longer and only one command to copy

May 27, 2021

Also when trying it with subfolders, I noticed, you may need to have the subfolders created automatically in your build-directory:

OBJS = $(shell find . -type f -name "*.cpp" | sed s/.cpp/.o/)

OBJS_DEBUG=$(foreach obj,$(OBJS),./.build/Debug/$(obj))
OBJS_RELEASE=$(foreach obj,$(OBJS),./.build/Release/$(obj))

CC = g++
FLAGS_DEBUG = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Debug/ -D_ULTRA_APPKIT
FLAGS_RELEASE = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Release/ -D_ULTRA_APPKIT
LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl
OUT = AppKit

all: debug release

debug: $(OBJS_DEBUG)
	$(CC) $(CONFIGFLAGS) $(OBJS_DEBUG) -o $(OUT) $(LFLAGS)

release: $(OBJS_RELEASE)
	$(CC) $(CONFIGFLAGS) $(OBJS_RELEASE) -o $(OUT) $(LFLAGS)


./.build/Debug/%.o: %.cpp
	mkdir -p $(@D)
	$(CC) $(FLAGS_DEBUG) $(CONFIGFLAGS) $< -o $@

./.build/Release/%.o: %.cpp
	mkdir -p $(@D)
	$(CC) $(FLAGS_RELEASE) $(CONFIGFLAGS) $< -o $@


clean:
	rm -f $(OBJS_DEBUG) $(OBJS_RELEASE) $(OUT)

This should now make for a pretty low-maintenance Makefile for your purposes

May 27, 2021

And for the topping (as I just found out): If you have want to have .o-files for every .cpp file in your directory, you can even generate the list more easily:

OBJS = $(shell find . -type f -name "*.cpp" | sed s/.cpp/.o/)

OBJS_DEBUG=$(foreach obj,$(OBJS),./.build/Debug/$(obj))
OBJS_RELEASE=$(foreach obj,$(OBJS),./.build/Release/$(obj))

May 27, 2021

Actually it turns out, there is an easy way for modifying the list of objects, which means, you don't need to hardcode the OBJS_DEBUG and OBJS_RELEASE-list. Instead you can do the following:

OBJS = ./AppKit.o ./Libraries/PluginSDK/GMFSDK.o ./Libraries/PluginSDK/MemReader.o ./Libraries/PluginSDK/MemWriter.o ./Libraries/PluginSDK/TextureInfo.o ./Libraries/PluginSDK/Utilities.o ./Libraries/PluginSDK/half/half.o ./Libraries/s3tc-dxt-decompressionr/s3tc.o ./Libraries/stb_dxt/stb_dxt.o ./Classes/Object.o ./Classes/Math/Math_.o ./Classes/Math/Vec2.o ./Classes/Math/Vec3.o ./Classes/Math/Vec4.o ./Classes/Math/iVec2.o ./Classes/Math/iVec3.o ./Classes/Math/iVec4.o ./Classes/String.o ./Classes/WString.o ./Classes/Display.o ./Classes/IDSystem.o ./Classes/JSON.o ./Functions.o ./Classes/GUI/Event.o ./Classes/GUI/EventQueue.o ./Classes/Language.o ./Classes/FileSystem/Stream.o ./Classes/FileSystem/BufferStream.o ./Classes/FileSystem/FileSystemWatcher.o ./Classes/GameEngine.o ./Classes/Clock.o ./Classes/Buffer.o ./Classes/GUI/Interface.o ./Classes/GUI/Widget.o ./Classes/GUI/Panel.o ./Classes/GUI/Slider.o ./Classes/GUI/Label.o ./Classes/GUI/Button.o ./Classes/GUI/TextField.o ./Classes/GUI/TreeView.o ./Classes/GUI/TextArea.o ./Classes/GUI/Tabber.o ./Classes/GUI/ListBox.o ./Classes/GUI/ProgressBar.o ./Classes/GUI/ComboBox.o ./Classes/GUI/Menu.o ./Classes/Window/LinuxWindow.o ./Classes/Timer.o ./Classes/Process.o ./Classes/FileSystem/StreamBuffer.o ./Classes/Multithreading/Thread.o ./Classes/Multithreading/Mutex.o ./Classes/Loaders/Loader.o ./Classes/Loaders/DDSTextureLoader.o ./Classes/Assets/Asset.o ./Classes/Plugin.o ./Classes/Assets/Font.o ./Classes/FileSystem/Package.o ./Classes/Graphics/Pixmap.o ./Classes/Graphics/Icon.o ./Libraries/CppTimer/CppTimer.o

OBJS_DEBUG=$(foreach obj,$(OBJS),./.build/Debug/$(obj))
OBJS_RELEASE=$(foreach obj,$(OBJS),./.build/Release/$(obj))

May 27, 2021

You can just change the rule to say `.build/Debug/%.o: %.cpp` and unfortunately you have to add this path everywhere in the OBJS-list:

OBJS = ./.build/Debug/AppKit.o ./.build/Debug/Libraries/PluginSDK/GMFSDK.o ./.build/Debug/Libraries/PluginSDK/MemReader.o ./.build/Debug/Libraries/PluginSDK/MemWriter.o ./.build/Debug/Libraries/PluginSDK/TextureInfo.o ./.build/Debug/Libraries/PluginSDK/Utilities.o ./.build/Debug/Libraries/PluginSDK/half/half.o ./.build/Debug/Libraries/s3tc-dxt-decompressionr/s3tc.o ./.build/Debug/Libraries/stb_dxt/stb_dxt.o ./.build/Debug/Classes/Object.o ./.build/Debug/Classes/Math/Math_.o ./.build/Debug/Classes/Math/Vec2.o ./.build/Debug/Classes/Math/Vec3.o ./.build/Debug/Classes/Math/Vec4.o ./.build/Debug/Classes/Math/iVec2.o ./.build/Debug/Classes/Math/iVec3.o ./.build/Debug/Classes/Math/iVec4.o ./.build/Debug/Classes/String.o ./.build/Debug/Classes/WString.o ./.build/Debug/Classes/Display.o ./.build/Debug/Classes/IDSystem.o ./.build/Debug/Classes/JSON.o ./.build/Debug/Functions.o ./.build/Debug/Classes/GUI/Event.o ./.build/Debug/Classes/GUI/EventQueue.o ./.build/Debug/Classes/Language.o ./.build/Debug/Classes/FileSystem/Stream.o ./.build/Debug/Classes/FileSystem/BufferStream.o ./.build/Debug/Classes/FileSystem/FileSystemWatcher.o ./.build/Debug/Classes/GameEngine.o ./.build/Debug/Classes/Clock.o ./.build/Debug/Classes/Buffer.o ./.build/Debug/Classes/GUI/Interface.o ./.build/Debug/Classes/GUI/Widget.o ./.build/Debug/Classes/GUI/Panel.o ./.build/Debug/Classes/GUI/Slider.o ./.build/Debug/Classes/GUI/Label.o ./.build/Debug/Classes/GUI/Button.o ./.build/Debug/Classes/GUI/TextField.o ./.build/Debug/Classes/GUI/TreeView.o ./.build/Debug/Classes/GUI/TextArea.o ./.build/Debug/Classes/GUI/Tabber.o ./.build/Debug/Classes/GUI/ListBox.o ./.build/Debug/Classes/GUI/ProgressBar.o ./.build/Debug/Classes/GUI/ComboBox.o ./.build/Debug/Classes/GUI/Menu.o ./.build/Debug/Classes/Window/LinuxWindow.o ./.build/Debug/Classes/Timer.o ./.build/Debug/Classes/Process.o ./.build/Debug/Classes/FileSystem/StreamBuffer.o ./.build/Debug/Classes/Multithreading/Thread.o ./.build/Debug/Classes/Multithreading/Mutex.o ./.build/Debug/Classes/Loaders/Loader.o ./.build/Debug/Classes/Loaders/DDSTextureLoader.o ./.build/Debug/Classes/Assets/Asset.o ./.build/Debug/Classes/Plugin.o ./.build/Debug/Classes/Assets/Font.o ./.build/Debug/Classes/FileSystem/Package.o ./.build/Debug/Classes/Graphics/Pixmap.o ./.build/Debug/Classes/Graphics/Icon.o ./.build/Debug/Libraries/CppTimer/CppTimer.o
CC = g++
FLAGS = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Debug/ -D_ULTRA_APPKIT
LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl
OUT = AppKit

all: $(OBJS)
	$(CC) $(CONFIGFLAGS) $(OBJS) -o $(OUT) $(LFLAGS)

./.build/Debug/%.o: %.cpp
	$(CC) $(FLAGS) $(CONFIGFLAGS) $< -o $@

clean:
	rm -f $(OBJS) $(OUT)

There is probably also a way to add it automatically to every object in the OBJS-list but I don't know it.

That later option is especially interesting, if you want separate debug and release builds:

OBJS_DEBUG = ./.build/Debug/AppKit.o ./.build/Debug/Libraries/PluginSDK/GMFSDK.o ./.build/Debug/Libraries/PluginSDK/MemReader.o ./.build/Debug/Libraries/PluginSDK/MemWriter.o ./.build/Debug/Libraries/PluginSDK/TextureInfo.o ./.build/Debug/Libraries/PluginSDK/Utilities.o ./.build/Debug/Libraries/PluginSDK/half/half.o ./.build/Debug/Libraries/s3tc-dxt-decompressionr/s3tc.o ./.build/Debug/Libraries/stb_dxt/stb_dxt.o ./.build/Debug/Classes/Object.o ./.build/Debug/Classes/Math/Math_.o ./.build/Debug/Classes/Math/Vec2.o ./.build/Debug/Classes/Math/Vec3.o ./.build/Debug/Classes/Math/Vec4.o ./.build/Debug/Classes/Math/iVec2.o ./.build/Debug/Classes/Math/iVec3.o ./.build/Debug/Classes/Math/iVec4.o ./.build/Debug/Classes/String.o ./.build/Debug/Classes/WString.o ./.build/Debug/Classes/Display.o ./.build/Debug/Classes/IDSystem.o ./.build/Debug/Classes/JSON.o ./.build/Debug/Functions.o ./.build/Debug/Classes/GUI/Event.o ./.build/Debug/Classes/GUI/EventQueue.o ./.build/Debug/Classes/Language.o ./.build/Debug/Classes/FileSystem/Stream.o ./.build/Debug/Classes/FileSystem/BufferStream.o ./.build/Debug/Classes/FileSystem/FileSystemWatcher.o ./.build/Debug/Classes/GameEngine.o ./.build/Debug/Classes/Clock.o ./.build/Debug/Classes/Buffer.o ./.build/Debug/Classes/GUI/Interface.o ./.build/Debug/Classes/GUI/Widget.o ./.build/Debug/Classes/GUI/Panel.o ./.build/Debug/Classes/GUI/Slider.o ./.build/Debug/Classes/GUI/Label.o ./.build/Debug/Classes/GUI/Button.o ./.build/Debug/Classes/GUI/TextField.o ./.build/Debug/Classes/GUI/TreeView.o ./.build/Debug/Classes/GUI/TextArea.o ./.build/Debug/Classes/GUI/Tabber.o ./.build/Debug/Classes/GUI/ListBox.o ./.build/Debug/Classes/GUI/ProgressBar.o ./.build/Debug/Classes/GUI/ComboBox.o ./.build/Debug/Classes/GUI/Menu.o ./.build/Debug/Classes/Window/LinuxWindow.o ./.build/Debug/Classes/Timer.o ./.build/Debug/Classes/Process.o ./.build/Debug/Classes/FileSystem/StreamBuffer.o ./.build/Debug/Classes/Multithreading/Thread.o ./.build/Debug/Classes/Multithreading/Mutex.o ./.build/Debug/Classes/Loaders/Loader.o ./.build/Debug/Classes/Loaders/DDSTextureLoader.o ./.build/Debug/Classes/Assets/Asset.o ./.build/Debug/Classes/Plugin.o ./.build/Debug/Classes/Assets/Font.o ./.build/Debug/Classes/FileSystem/Package.o ./.build/Debug/Classes/Graphics/Pixmap.o ./.build/Debug/Classes/Graphics/Icon.o ./.build/Debug/Libraries/CppTimer/CppTimer.o
OBJS_RELEASE = ./.build/Release/AppKit.o ./.build/Release/Libraries/PluginSDK/GMFSDK.o ./.build/Release/Libraries/PluginSDK/MemReader.o ./.build/Release/Libraries/PluginSDK/MemWriter.o ./.build/Release/Libraries/PluginSDK/TextureInfo.o ./.build/Release/Libraries/PluginSDK/Utilities.o ./.build/Release/Libraries/PluginSDK/half/half.o ./.build/Release/Libraries/s3tc-dxt-decompressionr/s3tc.o ./.build/Release/Libraries/stb_dxt/stb_dxt.o ./.build/Release/Classes/Object.o ./.build/Release/Classes/Math/Math_.o ./.build/Release/Classes/Math/Vec2.o ./.build/Release/Classes/Math/Vec3.o ./.build/Release/Classes/Math/Vec4.o ./.build/Release/Classes/Math/iVec2.o ./.build/Release/Classes/Math/iVec3.o ./.build/Release/Classes/Math/iVec4.o ./.build/Release/Classes/String.o ./.build/Release/Classes/WString.o ./.build/Release/Classes/Display.o ./.build/Release/Classes/IDSystem.o ./.build/Release/Classes/JSON.o ./.build/Release/Functions.o ./.build/Release/Classes/GUI/Event.o ./.build/Release/Classes/GUI/EventQueue.o ./.build/Release/Classes/Language.o ./.build/Release/Classes/FileSystem/Stream.o ./.build/Release/Classes/FileSystem/BufferStream.o ./.build/Release/Classes/FileSystem/FileSystemWatcher.o ./.build/Release/Classes/GameEngine.o ./.build/Release/Classes/Clock.o ./.build/Release/Classes/Buffer.o ./.build/Release/Classes/GUI/Interface.o ./.build/Release/Classes/GUI/Widget.o ./.build/Release/Classes/GUI/Panel.o ./.build/Release/Classes/GUI/Slider.o ./.build/Release/Classes/GUI/Label.o ./.build/Release/Classes/GUI/Button.o ./.build/Release/Classes/GUI/TextField.o ./.build/Release/Classes/GUI/TreeView.o ./.build/Release/Classes/GUI/TextArea.o ./.build/Release/Classes/GUI/Tabber.o ./.build/Release/Classes/GUI/ListBox.o ./.build/Release/Classes/GUI/ProgressBar.o ./.build/Release/Classes/GUI/ComboBox.o ./.build/Release/Classes/GUI/Menu.o ./.build/Release/Classes/Window/LinuxWindow.o ./.build/Release/Classes/Timer.o ./.build/Release/Classes/Process.o ./.build/Release/Classes/FileSystem/StreamBuffer.o ./.build/Release/Classes/Multithreading/Thread.o ./.build/Release/Classes/Multithreading/Mutex.o ./.build/Release/Classes/Loaders/Loader.o ./.build/Release/Classes/Loaders/DDSTextureLoader.o ./.build/Release/Classes/Assets/Asset.o ./.build/Release/Classes/Plugin.o ./.build/Release/Classes/Assets/Font.o ./.build/Release/Classes/FileSystem/Package.o ./.build/Release/Classes/Graphics/Pixmap.o ./.build/Release/Classes/Graphics/Icon.o ./.build/Release/Libraries/CppTimer/CppTimer.o
CC = g++
FLAGS_DEBUG = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Debug/ -D_ULTRA_APPKIT
FLAGS_RELEASE = -w -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./.build/Release/ -D_ULTRA_APPKIT
LFLAGS = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl
OUT = AppKit

all: debug release

debug: $(OBJS_DEBUG)
	$(CC) $(CONFIGFLAGS) $(OBJS_DEBUG) -o $(OUT) $(LFLAGS)

release: $(OBJS_RELEASE)
	$(CC) $(CONFIGFLAGS) $(OBJS_RELEASE) -o $(OUT) $(LFLAGS)


./.build/Debug/%.o: %.cpp
	$(CC) $(FLAGS_DEBUG) $(CONFIGFLAGS) $< -o $@

./.build/Release/%.o: %.cpp
	$(CC) $(FLAGS_RELEASE) $(CONFIGFLAGS) $< -o $@


clean:
	rm -f $(OBJS_DEBUG) $(OBJS_RELEASE) $(OUT)

You can use this and then execute either `make debug` or `make release` (Whereas you will probably want to adjust the FLAGS_DEBUG and FLAGS_RELEASE variables). If you only execute `make`, it will create both, debug and release.

May 25, 2021

You could shorten that a lot:

You don't need the definitions for SOURCE and HEADER at the top and you can replace most of your rules with a generic one:

OBJS	= ./AppKit.o ./Libraries/PluginSDK/GMFSDK.o ./Libraries/PluginSDK/MemReader.o ./Libraries/PluginSDK/MemWriter.o ./Libraries/PluginSDK/TextureInfo.o ./Libraries/PluginSDK/Utilities.o ./Libraries/PluginSDK/half/half.o ./Libraries/s3tc-dxt-decompressionr/s3tc.o ./Libraries/stb_dxt/stb_dxt.o ./Classes/Object.o ./Classes/Math/Math_.o ./Classes/Math/Vec2.o ./Classes/Math/Vec3.o ./Classes/Math/Vec4.o ./Classes/Math/iVec2.o ./Classes/Math/iVec3.o ./Classes/Math/iVec4.o ./Classes/String.o ./Classes/WString.o ./Classes/Display.o ./Classes/IDSystem.o ./Classes/JSON.o ./Functions.o ./Classes/GUI/Event.o ./Classes/GUI/EventQueue.o ./Classes/Language.o ./Classes/FileSystem/Stream.o ./Classes/FileSystem/BufferStream.o ./Classes/FileSystem/FileSystemWatcher.o ./Classes/GameEngine.o ./Classes/Clock.o ./Classes/Buffer.o ./Classes/GUI/Interface.o ./Classes/GUI/Widget.o ./Classes/GUI/Panel.o ./Classes/GUI/Slider.o ./Classes/GUI/Label.o ./Classes/GUI/Button.o ./Classes/GUI/TextField.o ./Classes/GUI/TreeView.o ./Classes/GUI/TextArea.o ./Classes/GUI/Tabber.o ./Classes/GUI/ListBox.o ./Classes/GUI/ProgressBar.o ./Classes/GUI/ComboBox.o ./Classes/GUI/Menu.o ./Classes/Window/LinuxWindow.o ./Classes/Timer.o ./Classes/Process.o ./Classes/FileSystem/StreamBuffer.o ./Classes/Multithreading/Thread.o ./Classes/Multithreading/Mutex.o ./Classes/Loaders/Loader.o ./Classes/Loaders/DDSTextureLoader.o ./Classes/Assets/Asset.o ./Classes/Plugin.o ./Classes/Assets/Font.o ./Classes/FileSystem/Package.o ./Classes/Graphics/Pixmap.o ./Classes/Graphics/Icon.o ./Libraries/CppTimer/CppTimer.o
OUT	= AppKit
CC	 = g++
FLAGS	 = -g -c -Wall -I/usr/include/freetype2 -I/usr/include/fontconfig -I./ -D_DEBUG -D_ULTRA_APPKIT -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl
LFLAGS	 = -no-pie -lm -lX11 -lpthread -lXft -lXext -lXrender -lXcursor -lrt -ldl

all: $(OBJS)
	$(CC) -g $(OBJS) -o $(OUT) $(LFLAGS)

%.o: %.cpp
	$(CC) $(FLAGS) $< -o $@

clean:
	rm -f $(OBJS) $(OUT)

This way, whenever you need to add a file, you just need to add it to the OBJS-list. The generic rule in the middle tells make, when it wants to create any file ending with .o to just search for the file ending with .cpp and in the command for that rule the placeholder $< will be replaced with the first prerequisite, whereas $@ will be replaced with the target (see https://www.gnu.org/software/make/manual/html_node/Automatic-Variables.html)

May 20, 2021

Yeah, basically every file starting with a dot belongs into the home directory because the starting dot is basically the Linux way of hiding files and that folder ist the only place where you would want to hide the files because otherwise they clutter your home directory (like on Windows your Documents-directory which is completely unusable for me because every program puts their data there)

May 18, 2021

You can change GDB's behaviour: https://ftp.gnu.org/old-gnu/Manuals/gdb/html_node/gdb_38.html

Something like

handle SIG33 nostop noprint pass

should do the trick (whereas SIG33 should correspond to SIGRTMIN). Just put any commands for disabling signals into your .gdbinit file.

December 24, 2020

Pretty sure "appstores" is wrong, though^^

December 24, 2020

I don't even know what the f*** is going on with all the appstores?^^

March 28, 2020

You might want to look at the return code:
in your batch-file add

echo %errorlevel%

directly after the game and before the pause

March 28, 2020

Is there a log in %LOCALAPPDATA%/Leadwerks ?

March 22, 2020

Have you tried temporarily turning off windows firewall?

March 13, 2020

9 hours ago, Thirsty Panther said:

As a general rule what are the strengths and weaknesses of arrays, vectors, maps and lists.

Arrays use a single continuous memory block. If you want to enlarge your array you need to copy all data to the new location. However, when you want to randomly index the array, this can be done in constant time, so accessing x[5] is just as fast as accessing the first element or the last one.

Vectors are basically a sort of managed arrays. They take care for reserving more space than you actually requested, so they can dynamically be increased and decreased in a limited manner without a performance hit.

Lists are usually linked one element to the next. This means, for accessing the 5th element, you need to call list->first->next->next->next->next. It becomes evident that random access on any member of the list is quite bad. However, if you only iterate over the entire list, handling each element in there, this can be done quite efficient. Of course, lists can be grown and shrinked without problems, since they do not have to be any continous blocks of memory. However, since you need to keep track of all the additional bookkeeping-elements, like references to the first, last, next and previous elements, you need more storage than in an array. Performance wise, the fact that they are not in a continuous block of memory also impacts the caching behaviour (but you probably won't notice unless you are using them quite intensively)

Maps are something quite different. They usually work by building a hash value of the corresponding keys and finding the corresponding list of elements that have the same hash-value in an array of buckets. They are usually well suited, if you have a key-value-pair, which you need to track. Both, insert- and lookup- operations require building of a hash-value, as well as an array access and iterating over a (usually very small) list of items in the corresponding bucket, so they have "rather constant" access times.

February 17, 2020

I suppose, that would be the case. There might be some other optimizations for brushes (e.g. if you want to have a sphere, you can simply transfer the center and the radius to the GPU instead of multiple vertices and again save some bandwidth and RAM real estate) but I believe that these differences would be only minor. I should say though, that I have never done any comparison nor do I have any specific knowledge of how this is implemented. Everything I'm saying about that topic is just derived from things I gathered in different forum posts here over the years and using my own logic

February 17, 2020

The difference comes from the fact that the entire thing is collapsed to just a single model. This means that every piece of code, which iterates over all instances only walks over this object once instead of 1000 times. Also there is only one transformation matrix which is getting updated and pushed back and forth from CPU to GPU and which takes much less space (which can be used for caching again)

October 29, 2019

16 hours ago, tipforeveryone said:

Is there any better solution to scan enemy in range ? I wonder if I have more enemy (50?), must I iterate through all of them each time I shoot to collect in-range one?

There is but that isn't trivial to implement: Basically you create a grid where each cell lists all the enemies within the region. This requires that when an enemy changes position, it also removes itself from the old cell's list and inserts itself into the new one. Then the player only has to search through the lists of the nearby cells. Of course the additional bookkeeping might have a different performance impact but especially, if the entities also sometimes react to one another or if you're checking the distance more often, this will certainly pay off.

October 12, 2019

The model probably does not have a surface. You should get the number of surfaces first and then iterate over the surfaces. Something like the following (I don't know much about lua, so probably this code won't work without modification):

for k,v in pairs (self.modelTable) do
    for i = 0, v:CountSurfaces(), 1 do
    	surface = v:GetSurface(i)
    	mat = surface:GetMaterial()
    	mat:SetShader(shader)
    	shader:SetVec4("ex_color",self.color)
    	mat:SetColor(self.color)
    	self.modelTable[k] = nil
    end
end

October 5, 2019

As I said, you should take a look at the objects on your map and the scripts they have attached!

October 5, 2019

I am pretty sure, the problem is coming from a LUA script of an object in your map, not from C++. That script has probably a world render or update hook, where it tries to access that variable.

October 5, 2019

9 hours ago, Jorns2 said:

In definition is virtual void Render();//lua. If i understand this good world->Render method is executed only in .lua script? Why ?

No, the comment "//lua" only means that this function is available in lua, as well, but that does not mean, that it is only executed in lua.

As for your other problem, it seems like you might not be setting the variable "world" before calling the Update-function or you are probably setting a function-local variable in the Start-function and then accessing a global variable in the update function or something like that. It's hard to say without seeing your code.

September 28, 2019

Also, looking at https://www.gamedev.net/forums/topic/673534-instancing-and-the-various-ways-to-supply-per-instance-data/?do=findComment&comment=5264179, you can create the buffer much larger first, then copy all data and later repeatedly use glBindBufferRange instead of glBufferSubData, copying all data in one go and being much faster

September 28, 2019

ah, I see, so you're refering to GL_MAX_UNIFORM_BLOCK_SIZE (https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glGet.xhtml)?

I think, it would make sense, to query that number in the beginning and use that instead of the fixed 256. Otherwise every system would suffer, only so that it can run on lower end systems.

EDIT: Of course I mean use that number divided by 64

September 28, 2019

Doing a performance-test with LW 4.7, I wanted to draw an element ins tanced multiple thousands of times. Using RenderDoc I found out, that Leadwerks batches these into groups of 256 elements each, so instead of having one call to glDrawElementsInstanced, instead I have quite many (which in my eyes are not needed). Also looking at the shaders, I found that they usually have a line like

#define MAX_INSTANCES 256

I believe that there is a lot of wasted potential because of this for rendering large groups of the same entity. Is there a reason for this limit? Can we increase it somehow? Will the same limitation be there in Turbo? I have attached the source code for my test.

App.h App.cpp main.cpp

Sign In

Blogs

Forums

Store

Gallery

Videos

Posts posted by Ma-Shell