Jump to content

Ma-Shell

Members
  • Posts

    371
  • Joined

  • Last visited

Everything posted by Ma-Shell

  1. This is pretty cool. I have a small suggestion though: The first scenario you showcased, could leave you with objects, which are not part of the scene-tree, resulting in inconsistent behaviour, if you do not call CreateSceneObject. I would suggest to have a callback-system like a ObjectCreated-hook built into the engine, which the editor then could use to automatically call CreateSceneObject with the new object. It makes for one less gotcha you need to watch for when writing scripts and imho better reflects the intention of the scene-browser as a way to see ALL objects in the scene. Also I can imagine this hook to be beneficial for other use cases. Of course, there would need to be a way to retrieve the scene-object for a given object, as well, since the user is not generating the element themselves anymore and thus does not have a reference if they need it (e.g. for selecting the object as in the example).
  2. 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.
  3. 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
  4. 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
  5. 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))
  6. 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))
  7. 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.
  8. 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)
  9. 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)
  10. 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.
  11. Please don't use Window::MoveMouse! You will have users constantly asking themselves, whether that's absolute (i.e. move mouse to x, y) or relative (i.e. move mouse by dx, dy). Even if you can easily look it up I think, it is more helpful when scrolling through the autocompletion-options to just see on the first look what the function does without ambiguities.
  12. Pretty sure "appstores" is wrong, though^^
  13. I don't even know what the f*** is going on with all the appstores?^^
  14. This is looking great. I've always been bothered by the available options for a lightweight GUI. I also think that cross platform support for a GUI framework is quite a big deal and can only second the opinion that this is the most important bonus goal. From the material you have posted, there is one thing I am quite curious about: In your code example you are placing the button and panel using fixed coordinates and sizes. Moreover, the widget is only created once and does not run through a loop, where the user would constantly recalculate the coordinates. When looking at the video, however, the widgets resize, when you resize the window. Did you implement a resizing-handler for the GUI shown in the video or are you planning to have a sort of automatic layouting system (i.e. defining anchors and having horizontal/vertical/grid layouts, which automatically manage the sizes of their contents) (clearly such a layouting system internally needs to use such a resize-event-handler but the question is, whether the logic behind that is tucked away some place within the API or whether a user needs to implement the handler themself). Maybe you could extend the example code by the GUI which is shown in the video and if there is such a system leave some words about how you plan it to work.
  15. You might want to look at the return code: in your batch-file add echo %errorlevel% directly after the game and before the pause
  16. Have you tried temporarily turning off windows firewall?
  17. 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.
  18. 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
  19. 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)
  20. What happened to where you claimed 200 fps for 10000 characters? Was that all shared skeletons?
  21. Ma-Shell

    Particle Physics

    This is certainly a pretty cool feature! Whenever physics is involved, however, the programmer needs to keep in mind that there might be slower systems out there and things might break when executed on slower systems. The programmer might e.g. be tempted to give an option to reduce the particle effects on lower end hardware but then the entire physics might break.
  22. I suppose, texcam will be rendered every frame, just like the normal camera. Would there be an option to render the camera only on demand? Like some sort of photograph? Or with a lower frequency for performance optimization?
  23. Are you using some fancy new technology like MVR or one of its predecessors for the single pass point-lights? If so, have you also evaluated, what happens on older GPUs?
  24. 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.
×
×
  • Create New...