Let's Code for the Uzebox?

What is a Uzebox? How can I get one? Check here!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Let's Code for the Uzebox?

Post by Artcfox »

Thanks! I'm trying my best to keep the videos concise, but there is so much stuff I want to demonstrate!

Future topics I'm planning out in my head:
  • Basic input handling
  • Sprites (ram tile planning)
  • Collision testing
  • TriggerFx() patches (and associated tools: PatchTool, Uzebox Patch Studio)
  • PCM patches (the installation, configuration, and demonstration of the Linux tools you need to go from a microphone/sound file, to a .inc file, how to save space by compressing your PCM samples)
  • Designing a MIDI from scratch (the installation, configuration, and demonstration of the Linux tools needed for that), then kicking things up a notch by adding a percussion channel to your MIDI.
The really nice thing about doing this with Debian GNU/Linux is that every tool required is just a

Code: Select all

sudo apt-get install name_of_tool
command away (if it's not already pre-installed!) so I don't have to spend any time at all explaining how to find, download, and install a ton of tools that may be scattered all over the web.
User avatar
shmitty
Posts: 4
Joined: Mon Mar 13, 2017 1:15 pm
Location: Antwerp, Belgium
Contact:

Re: Let's Code for the Uzebox?

Post by shmitty »

Matt,

Thanks for the time and effort to create these videos. They are extremely helpful to get started with uzebox programming. I look forward to the following videos in the series.

I know basic C. The hardest part for me to get started is how to handle common tasks such as input handling, game logic and display output in C using uzebox. I'm used keeping my code organized and modular in other projects and I'd love to learn more about structuring uzebox specific game code. How do you keep this stuff readable. I think developing an example game step by step (perhaps bugz?) in upcoming videos would go a long way into teaching us how to develop games for uzebox.

I started out with game development using the Python pygame library. Extremely helpful here were the tutorials by sentdex at pythonprogramming.net https://pythonprogramming.net/. He made an entire pygame tutorial video series using the game "snake" as an example (see https://pythonprogramming.net/pygame-py ... t-1-intro/. This was great because it gets your feet wet right away while building something you can actually have fun with and expand yourself in any way you like. His style tends to be a bit corny sometimes and it's not always as concise as your videos so far but it was a great resource.

I think your style is great and to the point. It's amazing how many things you cover fluently in just these first two videos. I really hope you find the time and drive to keep it going.

Thanks again,

Michael
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Let's Code for the Uzebox?

Post by Artcfox »

shmitty wrote:Matt,

Thanks for the time and effort to create these videos. They are extremely helpful to get started with uzebox programming. I look forward to the following videos in the series.

I know basic C. The hardest part for me to get started is how to handle common tasks such as input handling, game logic and display output in C using uzebox. I'm used keeping my code organized and modular in other projects and I'd love to learn more about structuring uzebox specific game code. How do you keep this stuff readable. I think developing an example game step by step (perhaps bugz?) in upcoming videos would go a long way into teaching us how to develop games for uzebox.

I started out with game development using the Python pygame library. Extremely helpful here were the tutorials by sentdex at pythonprogramming.net https://pythonprogramming.net/. He made an entire pygame tutorial video series using the game "snake" as an example (see https://pythonprogramming.net/pygame-py ... t-1-intro/. This was great because it gets your feet wet right away while building something you can actually have fun with and expand yourself in any way you like. His style tends to be a bit corny sometimes and it's not always as concise as your videos so far but it was a great resource.

I think your style is great and to the point. It's amazing how many things you cover fluently in just these first two videos. I really hope you find the time and drive to keep it going.

Thanks again,

Michael
Thanks! I'm glad you have found them helpful so far. I have thought about how to structure the next tutorials, and I think that I will end up creating a simple game while covering more stuff.

In the mean time, you can get somewhat of an idea on how my game Bugz evolved, by looking through its git history.

Thanks for the kind words!
User avatar
shmitty
Posts: 4
Joined: Mon Mar 13, 2017 1:15 pm
Location: Antwerp, Belgium
Contact:

Re: Let's Code for the Uzebox?

Post by shmitty »

In the mean time, you can get somewhat of an idea on how my game Bugz evolved, by looking through its git history.
That's a great idea Matt. I've cloned the bugz github repository, it's well organized. I was happy to see that even the initial commit compiles to something that works (the initial physics construct to play around in).

If you were indeed to cover creating a game in one (or more likely several) of your next videos, I'd be interested to see a brief intro on how to implement high school physics in C and apply it to a game construct to create the effects of friction and gravity as these are properties that seem to come back in many different games.
Probably like most programmers I am familiar with integrations and derivatives as you see these things pass by in school, but it's always great to see some practical application of this math. And what's more fun than to see it applied to a game, right?

Again, thanks for your time and sharing this knowledge!
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Let's Code for the Uzebox?

Post by Artcfox »

Cool, I'm glad it worked for you.

I think the first series of tutorials is going to be about setting up the tools, and going over sounds, but a physics tutorial would be cool.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Let's Code for the Uzebox?

Post by Artcfox »

I just completed a video tutorial demonstrating how to (starting from scratch with nothing installed) compose a multi-track, multi-instrument MIDI file with a percussion track using Rosegarden on Linux, and then how to convert and integrate that into a Uzebox project.

I think it's a pretty good introduction to Rosegarden, and the various features that one might need to know in order to use it to effectively create music tracks for the Uzebox, and at the end I tried to quickly go over a few advanced tips and tricks for working with Rosegarden.

(I'm still getting over a sinus infection, so my voice sounds a bit odd.)



The quality seems to be much better if you click on the link at the top of the video or click here to watch it directly on YouTube.

Let me know what you think!

Edit: Re-linked to new video, because in my first video I forgot to mention the Makefile changes required to support sound and the noise channel.
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Let's Code for the Uzebox?

Post by L4rry »

Artcfox wrote: Wed Nov 22, 2017 12:28 am I just completed a video tutorial demonstrating how to (starting from scratch with nothing installed) compose a multi-track, multi-instrument MIDI file with a percussion track using Rosegarden on Linux, and then how to convert and integrate that into a Uzebox project.
...
Let me know what you think!
I think the video was really helpful. From my perspective, the timing is also pretty good because I'm trying to figure out the sound engine once and for all :) This went a long way, but I do have some questions about the video (and I guess the sound engine in general):
  • You mention setting the SOUND_CHANNEL_5_ENABLE macro as this represents the noise channel, but isn't the 5th channel the PCM channel and the 4th channel the noise channel?. My understanding is that there are 3 wave channels, 1 noise channel and 1 PCM channel.
  • Around the 19 minute mark you talk about how the position of the two noise channel patches in the patches array should inform the position of the notes you use relative to the starting note of your scale. This threw me for a bit of a loop. So I assumed the order of the patches (at least for the first 4) corresponds to the order of the tracks in the midi song. This seems to be the case for the first three tracks, but not so the noise track, which targets two patches for a single track and then also seems to demand specific note placement based on the patch order. Is this unique for noise type patches (type=1), but not wave type patches (type=0) or am I misunderstanding the relationship between the patch array and midi song?
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Let's Code for the Uzebox?

Post by Artcfox »

Thanks!

Hmm, I'll look into the PCM thing. I just remembered something not working when I didn't have that in there, and I do plan on making a tutorial video about recording or importing PCM sound effects, and getting the conversions correct using all free and open source tools on Linux.

Yes, you are correct that the first three indices in the patches array correspond to the first three MIDI tracks, and then for the noise channel the actual MIDI note number corresponds directly to the array index for the noise patchs in the patch array.

So say you had 10 sound effects after the first three entries in your patches array, and then you had your percussion noise patches. Then you would have to skip the bottommost 13 keys on the scale on the fourth track in order for those note numbers to correspond to where the noise patches live in the patches array. If you have more than two noise patches, just keep placing notes up the scale to trigger them, but don't place any notes higher than the array index of your noise patch, or bad things will happen.

I think it would be awesome if it were possible to trigger PCM patches in addition to noise patches in this way, but currently I don't believe it is possible. If the sound engine supports this in the future then it would be really easy to trigger PCM samples in exactly the right places in songs.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Let's Code for the Uzebox?

Post by Jubatian »

Huh, nice to know about this!

At least for me Rosegarden was something new here, and I see it would be very useful to me as I can better conceive music with the visual matrix. I struggled with Modplug Tracker to realize the ingame music of Flight of a Dragon (maybe the second time I used a tracker in my life), and I found it still very difficult to tie the commands and their spacing in the pattern with what I hear. Hopefully with this knowledge I will be able to make something better for the final game (otherwise FoaD is not midi, it uses a special compressed format which I enter manually in hexa, the ingame music is about 300 bytes).

But of course it is nice to have this all working! By the way wouldn't it be possible to remove unnecessary stuff during conversion? (you mention it is better to join the segments in Rosegarden before export to get a smaller result in Uzebox, while as far as I perceive the split shouldn't contribute to anything audible)
User avatar
L4rry
Posts: 242
Joined: Sun Dec 28, 2014 7:19 am
Location: Cape Town, South Africa

Re: Let's Code for the Uzebox?

Post by L4rry »

Artcfox wrote: Wed Nov 22, 2017 4:21 pm So say you had 10 sound effects after the first three entries in your patches array, and then you had your percussion noise patches. Then you would have to skip the bottommost 13 keys on the scale on the fourth track in order for those note numbers to correspond to where the noise patches live in the patches array. If you have more than two noise patches, just keep placing notes up the scale to trigger them, but don't place any notes higher than the array index of your noise patch, or bad things will happen.
Thanks man. That actually clears up a lot of uncertainty for me. So it seems it's best practice to have your melody/lead and bass (or midi sound founts) in the first three patch array positions, your percussion (noise) instruments in the next few and your sound effects then following that in any order.

I now know why I had so much trouble getting any kinda percussion working for the Cyaron's Gate port in Iros! I can't help wandering if it would be worth separating midi sound fonts (first three wave channel patches), percussion (noise patches) and general sound effects into three separate arrays just for readability. Thanks for the tutorial vids. It really is insightful :) Keep it up!
Post Reply