kavika13 / jumpmanzero Goto Github PK

Content needs to be moved to its own project. It has its own build steps so it doesn't make sense to have it in the same project as the engine, especially for an automated build.

• Creates array with size 500, but then only initializes the vertex arrays in those objects to size 100
• Indexes level objects array without checking array bounds while loading level objects (> 500)
• Indexes level resources array without checking array bounds while loading level resources (> 500)

Need to fix all build warnings in JumpmanScripting project.

Need to create an automated build that can:

• Run unattended
• Support version numbering
• Compile Jumpman Zero executable
• Compile content toolchain
• Compile scripts, and other content (3D meshes?)
• Create installers for content (one for game and content, another for content toolchain)
  • right now these could be self-extracting executables and this would be fine
• Separate build artifacts to be published
• Place build artifacts in output directory

Automated publishing to GitHub would be nice, but it should go through a test pass on each release before this happens, and this is going to be a manual process.

Add tutorials to wiki for:

• High level: What the different content types are and how they are used
• Editing an existing level
• Adding new behavior to an existing level
• Basic level creation
• How to customize the music for a level
• How to customize sounds for a level (?)
• How to load existing content into a level (?)
• How to compile a level
• How to add a level to a level playlist (one of the difficulty-level .jmg scripts)
• How to create 2D graphics and animation
• How to compile a 2D graphic/animation into a mesh
• How to use a new mesh in a level
• The supported API exposed to scripts
• How memory is shared between scripts and the Jumpman Zero engine
• How to add new APIs to the Jumpman Zero engine for scripts to use

... plenty more. This should probably get split out into sub-issues.

Currently duplicated between Debug/Release builds for these projects:

• JumpmanGraphics
• JumpmanLevels
• JumpmanScripting

They current output to /bin/, and should output to /bin/Debug/ or /bin/Release/

Need to add a link to jumpmanzero-thirdparty in the readme under the building section. Finding the DirectX 9.0c October 2004 release is painful and unsafe.

For an automated build we'll need to create a command line executable front-end for the script compiler

We'll also want to avoid duplicating code, so we'll split out the script compiler code into its own shared library, and have both the GUI script editor and the command line compiler front-end use that library.

Create way to open a level for testing

Need to fix all build warnings in JumpmanLevels project.

The content creation application JumpmanGraphics has all its paths hardcoded to C:\Jump* directories.

This should at least use relative paths (current working directory?), and ideally would be user configurable.

• Link against extlibs: SDL2, SDL2_image, OpenGL, FMOD, Lua, Sol2, glm, jsoncpp
• Build game and copy assets so it will run straight out of build directory
• Build test project (Catch - unit testing library) so that it will run straight out of build directory
• Debug and release builds
• Rebuild source files when headers they depend on change
• Build all above on OSX
• Build all above on Windows
• Build all above on Linux
• Build OSX app bundle

1. Unzip game
2. Launch game
3. Go fullscreen (ALT + Enter)
4. Launch game level
5. Quit out
6. Launch game again

Expected:
Looks normal

Actual:
Tiny viewport!

Might be impossible at this point, but there are some sources missing for some of the binary levels/(scripts too?) that are in the zip I have.

Maybe David Campbell has some backups?

Couldn't do this in the B6 version. This makes certain levels much easier than they should be.
Need to build current version on master branch to see this issue.

Will binaries be made available? Actually I'm not sure if the project is runnable overall?

These content creation applications are in source control, but don't open and build cleanly in Visual Studio 2012:

• JumpmanGraphics
• JumpmanLevels
• JumpmanScripting

These need to be opened, upgraded, have all warnings taken care of, and have their includes/build targets corrected.

The wavefront obj loader in the new engine dumps all the vertices out for non-triangle faces (quads, etc), but not in any format the rest of the engine can handle. The rest of the engine assumes triangle meshes and doesn't have any face count data. There's no reason to make the rest of the engine support > 3 sided faces because it is going to pass triangles to OpenGL anyway.

None of our models have faces with more than three sides, so this is adding support, not really fixing a bug.

This level order is triggerd when playing the beginner level set in order

Create a way to trigger a script/function manually from in-game. Possibly some sort of developer console?

There should be a Credits option from the main menu. This will require:

• Get the main menu script working with a new compile.
• Change the main menu script to display a Credits option
• Change the main menu engine hooks to support loading the credits
  • Possibly make generic hooks so we don't have to make an explicit menu hook in the engine every time we change a menu script
• Possibly separate credits into its own level so it can be shared between the ending level and the main menu, without the main menu displaying the ending cinematic

Requires the new engine to be capable of loading a level and running level scripts. Scripts need to support manipulating 3D graphics, getting and react to user input, but not any actual gameplay.

Requires porting/augmenting of title screen scripts to use Lua.

Repro in title

For an automated build we'll need to create a command line executable front-end for the graphics renderer.

We'll also want to avoid duplicating code, so we'll split out the renderer code into its own shared library, and have both the GUI graphics editor and the command line renderer front-end use that library.

Need to fix all build warnings in JumpmanGraphic project.

• Create test level playlist
• Create test level for all letter meshes

• Embed them in application
• Delete path from app.config and generated settings code
• Delete path from config dialog

The content creation application JumpmanLevels has all its paths hardcoded to C:\Jump* directories.

This should at least use relative paths (current working directory?), and ideally would be user configurable.

There are some 50+ warnings when compiling under Visual Studio 2012 about not using C "safe" string functions.

These are simple to fix, but require some testing of each area that is touched.

For an automated build we'll need to create a command line executable front-end for the level "renderer"

We'll also want to avoid duplicating code, so we'll split out the level "renderer" code into its own shared library, and have both the GUI level editor and the command line "renderer" front-end use that library.

• Remaining lives (in script source/title.jms) looks like it is supposed to be using data/panel.bmp
• FPS display (in script source/title.jms) looks like it is supposed to be using data/panel.bmp
• Level title (in script source/title.jms) looks like its supposed to be using data/titles.png

There also seems to be some duplicate display of remaining lives in source/title.jms, though I bet one of the renders very small, or off-screen.

They all seem to be using data/titles.png though, even though the game script specifies otherwise, and the global level loading code loads both textures and appends them to the end of the texture list. I wouldn't be surprised of the script were out of sync with the compiled script binary, if the math for texture selection is off, if the duplication in the remaining lives display is partially to blame, or if the switching of textures multiple times in the same script function somehow is hitting a last-one-wins scenario.

There will be some investigation required, and this will require that source/title.jms be set up so it can be edited, compiled, and the resulting binary be used in the game.

The content creation application JumpmanScripting has all its paths hard-coded to C:\Jump* directories.

This should at least use relative paths (current working directory?), and ideally would be user configurable.

For an automated build we need to be able to:

• Build the script compiler
• Compile the script assets
• Compile graphics assets (.set files)?
• Copy the compiled and non-compiled assets to the engine output directory
• Compile the development tools
• Create packages of both

This requires all these various projects to be combined into one solution file.