gamercade-io / gamercade_console Goto Github PK

Currently, it's not possbile to move items around on the AudioList. This can cause quite the usability issue when users want to create many instruments, chains, etc, but are stuck with the original order they used with.

It would be good to have the option of re-arranging things things.

It's also important that when something is changed, the resulting references are updated. IE, if an instrument is moved to a different index, all of the phrases which reference that instrument should be updated to the new index. Same applies for chains, phrases, and songs.

It's common for sprite sheets to be saved as a large, single image, such as: a tileset or even character animations.

Currently, the editor expects them to be a series of individual image. This can be quite a hassle to split images if they are in the wrong file size.

I expect we can add some function like "Import Sprite Sheet" which will allow the user to select a single image, set the dimensions of the individual frames, and import those as a series of images into the Gamercade format.

It would be nice if the user could drag & drop a .wasm file into the editor in order to pre-load it for fast exporting.

The file menu has a button for "New" on palettes, but it currently doesn't do anything. This button should work when clicked and allow the user to generate a new file. Would also be good to do the "Are you sure?" dialog before performing the action.

The current UI is lacking in a lot of areas in the layout. Items are pretty much layed out randomly with very little organization.

This should be improved to increase the appereance and usability of the editor.

An example:

Which is made worse because for some reason it's even pushing the sprite-scaling option off the window with no way to recover.

The patterns have a volume level associated with them, and it is also already being passed accross the channel throughout the tracker.

We should use this to actually adjust the output volume of the note.

Currently, the sound_engine is single channel mono only. We need to support stereo at least. This might have some relation to the effects issue #51 but I think left/right panning shouldn't be limited to only effects.

This change would affect a few different areas, both in how Oscilloscope displays channels, how sounds are rendered through cpal, and also even how SampleData is stored on the data type. Do we store samples as stereo? Or keep them mono? Theres many ways to do it and currently I don't know what the best approach is, so I'm open to ideas here.

Primarily a discussion topic. See the primary issue over at console.

Currently, the color editor for palettes only displays them as independent RGB values.

Some users like working with Hex strings, so it would be good to have this.

Since these functions will exist in a future version, we should remove these buttons temporarily until we can properly add them in.

The buttons that need to be removed are:

• Export , from the Sprite Sheet Editor
• Color Swap, from the Sprite Sheet Editor
• Import, from the Sprite Sheet List

The file menu "Game" has an option for "Test Local Game", but it currently doesn't do anything.

This button should launch a single player game instance with the currently loaded rom.

I'm not sure on the best way to do this, maybe specifying the directory of the executable? Alternatively we coud embed the console in the editor somehow. Open to suggestions here.

It would be nice if the user could drag & drop a gce file into the editor in order to load it for faster re-exporting.

Related to:
#30
#26

Currently, the flow to test a game from a completely cold start is as follows.

1. Compile and build your output .wasm
2. Run the editor
3. File -> Open. Open the editor file.
4. Game -> Export Game Rom.
5. Find the output .wasm from previous steps.
6. Export the game rom.
7. Open the Console
8. Load the Game
9. Press Start Game

Now it can be sped up slightly if you have a few things set up first:

1. Compile and build your output .wasm
2. (Editor already open, .wasm file path already saved). Game -> Export Game Rom
3. Open the Console
4. Load game and press start.

But both methods involve a lot of tedious steps and moving between multiple programs.

It would be nice if we could do something like pass in the game file location, designate that it's a local game session, and launch the console with those things already prepared.

Since these functions are unimplemented, we should remove them.

Rename has already been implemented through another means, so this button is useless.

We may add Export at a later date but currently it's not am important feature.

It would be nice if the user could drag & drop a .gcrom file into the console in order to load the game.

I think it's fine if this automatically starts a single player game, but I'm not too picky. It could be good just to put the game & load it and then wait for the final "start game" button press.

These functions exist in the codebase at some point but are not implemented and should be removed:

• draw_text
• bgm_is_active
• channel_is_active

This includes changes to gamercade_rs, and gamercade-console, as well as any changes to documentation on the website

While the tracker data for phrases actually includes a volume level, they are completly ignored for the sound playback. We need to add this featue!, as currently sounds are just always played at full volume.

It would also be good to default the volume level to something like 127, 128, or something in the middle to give users some more flexibility to move volume both up and down.

This is a tracking issue for any tasks which need to be completed prior to announcing our first real release. If theres any other tasks you think might be important or critical to it, please reply to this issue and make suggestions.

The "Nice To Haves" List I can see as being priority issues in the near future/future releases.

Hard Requirements:

• Site Documentation
  • gamercade-io/gamercade_site#3
  • gamercade-io/gamercade_site#4
  • gamercade-io/gamercade_site#5
  • gamercade-io/gamercade_site#10
  • gamercade-io/gamercade_site#11
  • gamercade-io/gamercade_site#14
  • gamercade-io/gamercade_site#15
• #24
• #50
• #31
• #13
• #55
• #56
• #10
• #57
• #60
• #64
• #72
• #74
• #76
• #2
• #6
• #77
• #3
• #4
• #63
• gamercade-io/gamercade_site#8
• #8
• #42
• #61
• #22
• #68

Nice To Haves:

• #62
• #9
• gamercade-io/gamercade_site#9
• #47
• #71

After Launching a game, the user cannot load another game without closing the application and completing the process entirely.

We should allow users the ability to load/launch other games while one is running.

There are a lot of places which need documents. We should at least try to completely document all of the public facing functions. I will organize this by file for now.

General

• Rom
• mod file const values
• Readme

Graphics

• color
• frame_rate
• graphics_data
• graphics_parameters
• palette
• resolution
• sprite

Since one of Gamercade's core features is being language agnostic, we need more examples, bindings, for other popular WASM languages.

Feel free to request any more languages, and I'll add them to this list.

Some other "nice to have" languages could also be:

• Odin
• D

Lots of retro consoles had built-in features, like reverb, echo, delay, as well as note-level effects like slide or arpeggiators.

I think it would be good to discuss some potential approaches and some effects we could start developing 2-3 effects as a proof-of-concept. The Phrase struct already has the array of three Option<Effect> to use, so we can easily plug into there.

Currently, the tracker relies on extremely short "activation" times for notes within patterns. This is done via trigger which instantly moves the button to an off state after the first tick.

It might be better to instead have notes be held or active as the tracker progresses through the patterns, and allow the user to specify an actual cutoff point.

We would need to adjust the PhraseEntry struct (possibly to an enum) to allow different kinds of entries.

A common feature among other samplers is to set loop points within the sample.

This means that the sound can play from beginning to end, and then afterwards loop between two designated positions. This is useful in percussive type sounds, or instruments like a piano, where the initial hit sound is unique, but if held, the long-lasting resonating sound continues to play.

I'm not sure if the end point should be configurable or not, but at least the start point should be.

We should also be able to set loop modes:

• Pure cyclic can simple go from start -> end and repeat. Like a pure sine wave.
• Loop Point should play from start -> end, and then loop between specific points within the sample. Like the piano example above.
• One-shot should play once from start -> end, and then never repeat. Like a drum.

Curretly, the GraphicsParameters does have the option to flip x & y, but this doesn't actually do anything when passed to the console.

We need to allow this functionality since the only alternative currently is to make 2x art assets, one for each direction.

Now that bgm_is_active and channel_is_active are removed, we need a way to notify the game logic how long a sound will last.

I propose adding two more functions to the data_api

1. bgm_length_secs(index: i32) -> f32 which returns the length of the BGM in seconds.
2. bgm_length_frames(index: i32) -> i32 which returns the length of the BGM in frames.
3. sfx_length_secs(index: i32) -> f32 same as 1, but for SFX.
4. sfx_length_frames(index: i32) -> i32 same as 2, but for SFX.

While we don't have looping BGM or SFX yet, I figure we could use INFINITY or NaN or a negative number to represent looping ones in the future.

For the "frame" based ones, this should be an integer for the sound to completely complete. For example, if a SFX would take 15.5 game frames to complete, it should return 16.

Task List:

• Figure out how to calculate length of a sequence in seconds (f32) from the BPM
• Figure out how to calculate the length of a sequence in frames, from the previous step.
• implement bgm_length_secs
• implement bgm_length_frames
• implement sfx_length_secs
• implement sfx_length_frames
• update gamercade_rs with 4 new functions
• update docs with 4 new functions (gamercade-io/gamercade_site@c1675e7)
• Add UI label on song editor to show song length
• Add UI label on SFX editor to show sfx length

When loading a sample in the editor, users have to either select None for the frequency, or know the frequency of the sample file itself. There are algorithms which can be used to give a best guess of the frequency.

This should be exposed as a button that the user can click, so if for some reason the algorithm results in a wrong value, they can use another method to get it.

The bare minimum documentation has been written, but the format is far from idea.

It should be improved to allow users to much more clearly understand the Api. Things like line breaks, inner links, etc.

Currently, the readme is just a bunch of my local notes.

Would be nice to have something much more welcome to future users & contributors.

I noticed that, in stand-by, the Editor consumes quite a lot of CPU resources even though it shouldn't as there is no event triggering any functionality in the UI.

I'm running the editor using the command: cargo run --release --bin gamercade_editor

There is always 100% usage in the thread running gamercade_editor, but ideally it would be almost negligible as its idle most of the time.

Interestingly enough, I noticed that if I interact with the program (moving the mouse around in the application, or clicking into buttons) the CPU usage actually drops to 0.6% ~ 4.2%.

Maybe when the editor is idle, the even loop simply runs at max speed without any sleep or something like that?

My system specs:
CPU: AMD Ryzen 9 5950X (32) @ 3.400GHz
GPU: NVIDIA Geforce RTX 3050
Memory: 32GB
(not sure if it's relevant, but using i3wm)

$ uname --kernel-name --kernel-release --kernel-version
Linux 5.15.60-1-MANJARO #1 SMP PREEMPT Thu Aug 11 13:14:05 UTC 2022

Currently, the console assumes only one local player.

GGRS does feature the option to have multiple local players, and also handles the network connection/logic/loop for it.

We should support this feature.

I expect that the max player count should be around 4-6, including both local & remote players. May have some potential conflicts with #1 or #2

Currently, we force users to generate both the FM Synth lookup table SIN_LUT and the Notes lookup table NOTES_LUT during initialization. This is quite tedius during tests and prone to user error.

It's possible to generate constant values and import them through a build.rs script.

Graphics Parameters and such can be confusing, as well as how sprite sheets & sprite images are layed out. We could use a simpler example here.

This example should have:

• A single, static image.
• A couple imported sprites within a spritesheet.
• A way to adjust sprite indices, and palettes.
• An animation.

Currently, all of the controls are hard coded.

It would be good if users could bind their own keys.

I think using a key configuration .json would suffice and just saving/loading this as necessary.

The UI has a button for "Rename " on palettes, but it currently doesn't do anything. This button should work when clicked and allow the user to rename the palette.

When trying to call draw_lines and passing bounds outside of the window, the line will sometimes appear or not, depending on start/end position.

We should draw lines across the screen regardless of the location, assuming it actually has pixels inside of the screen.

We currently have a console_log function, we also have the beginnings of a draw_text implementation.

This function would draw text on the screen at the specificed location, similar to drawing a sprite.

How should we represent fonts?

• They could be built-in to the engine. We could support multiple font heights, since the console also has multiple potential resolutions.
• They could be similar to sprites, where we add an additional layer on the ROM and Editor to support the drawing of fonts. The drawing code could just "stamp" fonts in place similar to drawing of a sprite.
• Are we limiting it to 1-bit fonts? 2-bit? Or something else?
• What character set are we supporting? ASCII? How about foreign-language characters?
• Is there a default font we can include (and distribute) ?

I think it would be good to keep it simple and restrict it to monospace fonts - however, I'm not picky on this. But I think anything more than this is out of the scope of the feature. For example, we shouldn't need to pass in things like wrapping settings, justification, etc.

It could also potentially open up some nice hacks/tricks where developers use drawing of fonts as an alternative for sprite drawing.

What do users/developers want out of a "Draw Text" function?

• Please post your ideas as replies to this :D

Currently, the console only supports keyboard inputs. Once gamepad support is added via #2 , we need a way to emulate some of those input types.

For example, WASD could simulate the left stick. Mouse location on screen could simulate the right stick.

Currently, the oscilloscope only displays the "combined output."

It would be nice if the channels option was actually implemented, and users could view individual channels, or all 8/16 all at once.

It's possible to convert the whole input state into ~60-64 bites of data. This can then be used as the return of the as_raw_state functions.

I believe it could look something like this:

• 16 bits for all button states. ABCD, start, select, up, down, left, right, R1, R2, R3, L1, L2, L3
• 32 bits total for analog sticks. 16 bits per stick (two sticks total), and each stick can have x and y represented as an i8.
• 14 bits for analog triggers. Can be stored as a 7-bit value from 0-127 (or an i8 with the sign bit removed)

This actually leaves us at 62 bits. The last two can be used to signal a bad input state, such as when the wasm requests a player_id which is out of the range of connected players.

In the future I could see some alternative version where we use only 60 bits, by removing the R2/L2 as buttons and relying on the analog trigger data. Alternatively, down to 48 bits if we just scrapped analog triggers entirely.

Long term considerations:

We also may want to allow mouse input in the long term future, so it would be good to consider how to potentilaly represent that state as 64 bits too. For example, triggers or analog inputs and giving us room for pixel-perfect UI screen coordinates for mouse (11 bits to each to support 1920 x 1080 resolution).

This issue is tracking the development of audio support in the console.

Currently, this include a few main action items:

• Determine what audio methods we can support: samplers, FM synthesis, something else?
• Add in audio playback to the console
• Add sound & music editing to the editor: related issue
• Inclusion of presets

There's a lot of different ways to produce audio. Simple wave forms like sin, square, saw, are ok but it doesn't really fit the goals of the project. I initially wanted to go with an FM synthesizer, a la audio-test but theres a few issues. One, I'm not even sure if my FM algorithm is correct. Unfortunately DSP is a bit out of my expertise but I did what I could. And Two, FM Synthesis is really hard to understand - even by professionals. Three, it's great for certain kinds of sounds, but not so great for percussion like drums and other SFX.

I think it does sound really cool, such as the old Sega Genesis/Megadrive and old DOS games which utilized these heavily, and really gives off this neo-retro vibe. I think we should support a FM synth at some point in the future, but not initially.

So the now proposal is to go with a sampler like the SNES. Let users import/load samples directly from disk and provide some framework to allow them to play different notes on the scale, play add different effects, and such. However I'm really not familiar with this kind of technology at all and don't even know where to start development on it.

Useful links about audio programming:
http://map.grauw.nl/resources/sound/yamaha_opl4.pdf
https://www.fit.vutbr.cz/~arnost/opl/opl3.html
http://jp.oplx.com/opl2.htm
https://doomwiki.org/wiki/OPL_emulation

When running a game, there's no way to ever restart it without closing the entire program. This means for testing gameplay, it becomes a tedius process of run console, load game, start game, test, close console, run console, load game, start game, test etc etc.

It would be nice if there was a reset button, which when pressed resets the current game to the initial state. This shouldn't prompt the user to open another game, but instead just restart the current one.

I think this could be done via messing around with the wasmtime stuff, or by potentially initialzing a whole new WasmConsole. I think the new console technique will be the most bug-free, but it also has the highest performance cost, so it would be better to find an alternative. Bonus points if it can also work over the network state too!

When trying to call draw_circle and parameters in which include pixel coordinates outside of the screen, nothing is draw.

We should draw the circle's pixels on screen, regardless of location, assuming it actually has pixels inside of the screen.

I’m guessing the plan is to eventually have a page on gamercade.io that’s the equivalent of this one? https://wasm4.org/play

It’s probably the most effective way of explaining what this console-thing actually does. Might be a contributor-friendly task as well, at least after some initial skeleton page has been put together.

Currently, only keyboard support is functional.

I recommend using this crate: https://crates.io/crates/gilrs

We currently have a draw circle function which is generally correct (minus some bounds issues pending #4). However we don't have a draw circle filled function to match that of the rectangle ones.

I except this can be done quite easily by using the same logic to find the outer pixels, and then calling horizontal line repeatedly until the circle is completely filled.

The Sprite Sheet Editor currently has very minimal features. We also need to implement the following buttons (already present in the UI):

• Color Swap - Lets the user swap all instances of one color index with another.
• Move Left
• Move Right
• Move List Up
• Move List Down

As the title suggets. We should find a way to remove this - but I actually have no idea where to start with this.

Could be related to #26 and #12

Currently, the flow to test a game from a completely cold start is as follows.

1. Compile and build your output .wasm
2. Run the editor
3. File -> Open. Open the editor file.
4. Game -> Export Game Rom.
5. Find the output .wasm from previous steps.
6. Export the game rom.
7. Open the Console
8. Load the Game
9. Press Start Game

Now it can be sped up slightly if you have a few things set up first:

1. Compile and build your output .wasm
2. (Editor already open, .wasm file path already saved). Game -> Export Game Rom
3. Open the Console
4. Load game and press start.

But both methods involve a lot of tedious steps and moving between multiple programs.

It would be nice if we could do something like pass in the .wasm file location, the .gce file location, output directory, etc. Ideally, we could build a nice one-line script to both compile the game, export the ROM, and the launch the console.

This could also help with building "packages" and downloads for the website, to include both the console itself with a few example projects or games.

Since the Tracker UI displays everything as hex indices, it can be difficult to remember exactly what is referencing what.

It would be nice if there was an option to "go to definition" on the field you're currently editing.

For example, if you are writing a phrase, and go to instrument definition, it will jump to instruments tab and select that instrument ID.