在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:ensisoft/gamestudio开源软件地址:https://github.com/ensisoft/gamestudio开源编程语言:C++ 98.7%开源软件介绍:GAMESTUDIO 2DA 2D game engine and editor for Linux, Windows and HTML5. Designed for simple single player games such as puzzle games, platformers and side scrollers. Eventually support is planned for tile based games too for real time strategy/tactics. This readme and other readme files, are for developers and cover information related to developing and building the engine itself. Other readmes: Currently supported major features:
Planned major features not yet implemented:
Planned minor features not yet implemented:
Create your animated game play characters in the entity editor. Each entity can contain an arbitrary render tree of nodes with various attachments for physics, rendering and text display. Animation tracks allow changing the properties of the nodes and transforming the tree itself over time. Each entity type can then be associated with a Lua script where you can write your entity specific game play code. Create materials using the material editor by setting some properties for the provided default material shaders. Currently supports sprite animations, textures (including text and noise), gradient and color fills out of box. Custom shaders can be used too. Create the game play scenes using the scene editor. The entities you create in the entity editor are available here for placing in the scene. Viewport visualization will quickly show you how much of the game world will be seen when the game plays. Create the game's UI in the UI editor. The UI and the widgets can be styled using a JSON based style file and then individual widgets can have their style properties fine tuned in the editor. The style system integrates with the editor's material system too! Create audio graphs using the audio editor. Each audio graph can have a number of elements added to it. The graph then specifies the flow of audio PCM data from source elements to processing elements to finally to the graph output. Currently supported audio backends are Waveout on Windows and Pulseaudio on Linux. Supported formats are wav, mp3, ogg and flac. Use the built-in code editor to write the Lua scripts for the entities, scenes or for the game. The editor has a built-in help system for accessing the engine side Lua API documentation. During the development the game is available for play in the editor. It's possible to do live edits to the game content in the editor and see the changes take place in the play window. Build InstructionsWASMBuilding to WASM currently supported only for the engine but not the editor. The build is separated from the main engine build and is in emscripten/ folder.
On Linux
-- Check your Emscripten installation
On Windows
-- Check your Emscripten and Ninja installation
If everything went well there should now be GameEngine.js and GameEngine.wasm files in the editor's dist folder. The .js file contains the JavaScript glue code needed to manhandle the WASM code into the browser's WASM engine when the web page loads. When a game is packaged for web these files will then be deployed (copied) into the game's output directory. Penguin Juice (Linux)
Then in order to profile and analyze the output use the combination of valgrind and kcachegrind. For example:
Boring But Stable (Windows)These build instructions are for MSVS 2019 Community Edition and for 64bit build.
Build the project in RELEASE mode.
Build the project in DEBUG mode.
The Boring DocumentationWorkflow and getting startedGoing from a git clone to a running game is known as the "build workflow". This involves various steps involving the source tree of the engine, the source tree of the game, the runtime assets provided with the engine and the runtime assets that are part of the game. Overall this will involve several build and packaging steps. Currently, only Lua based games are supported. There's a provided game engine that is built into a shared library and which contains all the relevant functionality for running a game. That is it will take care of rendering the scene, ticking the physics engine, handling the UI input as well as invoking the Lua scripts in order to run your game code. It's possible to also not use this provided engine but write a completely different engine. In this case the interface to implement is the "Engine" interface in engine/main/interface.h. From source code to a running game:
System ArchitectureAn overview of the runtime architecture:
Inside the game engine the following will take place.
Running (Unit) TestsThere'a bunch of unit tests that are built as part of the normal build process. Basically anything that begins with
a "unit_test_" is a unit test. There's a very simple testing utility that is available in base. test_minimal.h
Currently, the expectation is that all cases should pass on Linux. On Windows some of the tests are unfortunately broken. In addition to having the unit tests both the audio and graphics subsystems also have "rendering" tests, i.e. playing audio or rendering stuff on the screen. The audio systems do not have any automation for checking for correctness. The graphics tests work based on a set of gold images. The images are provided as part of this repository but there's the problem that because of the differences in OpenGL implementations it's possible that the rendering output is not exactly the same between various vendors/implementations (such as NVIDIA, AMD, Intel etc.) This needs to be enhanced so that a set of gold images could be tagged with a vendor tag and multiple gold images per test could exist. (This is a todo for later) It's also possible to run the audio/graphics tests separately. Runs, mp3, ogg, flag and 24bit .wav test. Use --help for more information.
Runs all tests with MSAA4. Any test rendering that differs from the expected gold image will stop the program for user input (press any key to continue) and will generate a Delta_ and Result_ images. The former will help visualize the pixels that were not the same between result and gold and the result will be actual rendering result in whole. Use --help for more information.
Coding Convention & Design
Tracing & ProfilingWhat follows is only specific to Linux. I don't know the tools for doing this on Windows. The engine has very primitive tracing built in. Most of the top-level subsystem calls to update all subsystems and to render the scene are wrapped inside trace calls. (The macros and tracing facilities can be found in base/trace.h)
The tracing can be turned on in the GameMain application by providing --trace parameter with a name to the file where to record the trace. There are 2 formats that are supported. A simple text format and a JSON format that is compatible with Chromium's trace viewer. So for example to trace blast demo one first needs to build the release package of the game (in GSEditor) and then navigate to the that directory and launch the game.
This should produce a trace.json file which can be loaded in Chrome/Chromium. (Open a new tab and open about::tracing and hit the Load button) The top most bar of every frame (MainLoop) is the overall frame trace and should not exceed your swap interval. In other words if you're running with VSYNC turned on (see your game's config.json) this should not exceed your maximum frame time which is computed as 1.0 / hz. (Where hz is your display's refresh frequency). In any frame most of the time should be spent in Device::Swap given the computational capacity of a modern computer and GPU and the simplicity of the games in this package. Overall all frames are composed of the following sequence:
The tracing allows to quickly get an overview of the frame structure and find out where the frame time is spent. This is ideal for quickly seeing the janky frames and getting some idea what's going on. The hard problem will be then figuring out more details of the part that is going wrong. One option is to pepper the code with more trace macros. The alternative is to use a profiler such as valgrind. Valgrind + callgrind + kcachegrind The biggest problem with valgrind is that it cannot be used for the entire application. It'll be far too slow and the game will not be able to run properly. Instead, the profiling needs to be turned on and off only for parts of the code. I've experimented with writing little snippets like.
This isn't the simplest way to do to it and requires having to rebuild the game engine but definitely allows for the most fine-grained control as-to when to capture the profiling information and can limit the instrumentation to a scope that is actually manageable and keeps the game still in a runnable state. Then in order to run game with the profiler do:
Once the tracing and profiling has ended use kcachegrind to open the callgrind chart.
https://valgrind.org/docs/manual/cl-manual.html#cl-manual.basics |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论