My projects and demos

[Pangit]

Today's update:

Well - turns out I was doing missing something obvious. Lol of-course the mouse position was messed up - I was not informing SUIT about the camera. I knew it would have been something obvious I was doing wrong. Still one line of code fixes the problem.

Code: Select all

Suit.updateMouse(cam:mousePosition())

Will adjust the positioning so is perfect and that's mouse support done for the character stats menu.

Might also do a mouse over graphic for the mouse on the menu bar.

Now all inputs are supported in the menu except touch. (I can't test that so its kind of hard to implement.)

Once I have the buttons all triggering on the mouse its going to be time to put this code into the skeleton framework version of the project I have. That will be the first update where its all working with hump.gamestates and not all jumbled together into one huge main file.

Next on the list will be adding in the actual meat and potatoes of the character stat generator to the demo. Yes there actually is a bare bones menu and functionality outside of the character stat information menu lol. Basically today is brining together all the separate parts of the program I had worked on. Where there are assets for stuff I did for different parts of the program I will include them also. Going to be a lot of place holder type screens. But your get the idea of what's going on and it should start to look more like a game. (just not one with too much going on at the moment lol.)

Have been looking at how isometric tile-maps work in tiled and its a bit like hocus-pocus to me at the moment lol., While I would like to use isometric tile in the game its currently not on the cards as my window-licker brain can't figure out how to do it. What I can do for now is top down tile maps. So I figure until like the 2001 ape I can touch the obelisk and gain enlightenment its better to get something working than nothing. Anyway you guys will see it later. Once again I am probably missing an obvious trick with that. lol.

Tonight's updates:

Had a great day with lots of progress. Mainly in assets. Having spent a few hours relearning how to use a tracker, I can now create some nice tunes for my games. This is great because while there are some excellent resources out there for use. It's always nice to be able to make something exactly as you want it for the game. The program I use on linux to do the tracking is milkytracker. Its very similar to trackers that you used to get on the commodore or the atari ST back in the day. If you are used to that sort of program you will pick it up extremely quickly. What I like also is you can create some very complex tracks with very little. As it stands each hub could have its own theme. Different music for different scenes. Game over themes, powerup fanfares ect..

On the programming side of life - have the character stats menu now working with mouse support. been getting the skeleton scenes done for the rest of the program with place-holders. and am trying to keep everything straight and planned out on a big sheet of paper I have on the wall. Hopefully that will keep things from getting too crazy and its good to be able to see the overall plan. I can just cross them off as I finish each part.

[Pangit]

Updates:

While re-learning how to use the tracker software, I got to thinking what if the program itself could adapt its music playlist based on player performance in game. Now this will not set the world on fire, its very common sound design theme. But I wonder how responsive and fine grained you could make it. The major limitation I can see is having to have the assets in a bank to draw from to cover all the edge cases.

But what if you didn't do that...

Assuming that your theme tune was pretty basic melody & base. with a few parameters passed to a function it should be possible to have it have a table of effects, rifts, instruments ect it could choose from that would change the music that the player hears based on his or her choices. It would also not require a great deal of resources because that file they are listening to is junked after play.

This is where having all those variables/statistics in game comes in handy based on the characters randomly generated stat list, the players choice of skills and variables that are set/unset during game play that could be passed to the music generator function to produce a fairly unique sound experience (probably not so good, but I am more willing to go with the cool idea than a perfect peter sounding background music. If the program occasionally makes a bad choice of music thats ok.)

With this approach you can also pass that music generator feedback from the game itself, player position ect.

Of-course theory is simple, implementation is hard.

[Pangit]

Updates:

Well things are looking up. The procedural generation of music assets might be more possible than I once thought. Due to a number of great books I was able to track down that had some great rules of thumb to flat out algorithms for generating rhythms and drumbeats. At least now I can pair this say with a lead that shares a common timing and it should be fine.

Like I said before it does not have to be perfect, just good enough. been looking at the mod file format as a way to generate these tracks. But ideally I would like to use xm. Mod is a much more limited file spec but its easier to understand and appears to be better documented. I need to read more of the programming in lua book to really nail this.

https://greg-kennedy.com/tracker/modformat.html

I had toyed with the idea of just splitting out the component tracks and merging them on-the fly in game with TEsound but I think there will be issues with timing and synchronizing the assets playing. But I could be wrong. If there was a precise way to lock the time to play the tracks together at the same time it would remove the need to bake the completed file. you could just randomly generate the structure and load the components as needed.

If anyone knows if this is possible (getting precise timings with sound assets playing at the same time.) then please feel free to write.

[zorg]

Both with modules and streamed sources like wav/ogg/mp3, simultaneous playback should not drift noticeably (or at all even), at least that was my previous experience.

That said, i've worked on parsing s3m modules, and apart from the playback routine, i managed to load in the data into löve all on the lua side. I plan on coding a playback routine too that pushes data realtime onto OpenAL (using a neat queuablesource lib) which would make it possible to programmatically jump to various orders of a module file from within löve itself (and to mute/unmute specific tracks as well)

However, this is still just a subpar way of doing things, since it'd be better to use a more mature lib, like libopenmpt for parsing (at least).
Still, it's a good coding excercise.

[Pangit]

Thanks for the pointers zorg I will take a look at the libs mentioned and go from there. But agreed it would have been a pretty cool programming exercise. I am still curious about how to write the mod file from lua - I think its a nice target because its so well documented and its pretty well defined. That would be a "gateway drug" type experience to get into writing that custom packer format I mentioned when I joined the site lol.

Prepare for cheesy 80s new-wave game soundtrack.

[zorg]

Fair warning though, mods are everything but well documented... well, no, that is to say, there exists a dozen docs for the format, both specs and implementation-wise, and many trackers/players are opensource, so one can check on the loaders for those (openmpt for one, schismtracker is also interesting, and there's one more for android, XMP i think), but there are many tiny little caveats that ensure that many tracks won't play correctly, no matter how you implement it*. Mostly the effects are affected; amiga used one kind of timings, PC-s used another; the MOD format existed on both. It also has an internal 4-byte "string" denoting what type of mod it is... unless it was made by a very old protracker on amiga... so yeah, it's very complicated to deal with all the inconsistencies, supporting all possible mod files.
The two biggest trackers on pc (openmpt and schism) both use horrific heuristics to guess at modules... or worse, they defined specific modules as exceptions in the loader code itself.
* It is possible to create a loader that deals with everything correctly, but only through user-intervention.

[Pangit]

Hey Zorg, I have been using milkytracker, I tried some protracker clones but then with the features you get with milkytracker and it not being as complicated or ugly as openmpt lol.. I decided to use that to make the game sound assets. I can add effects/processing in lmms after. That was the plan. Resource wise it shouldn't put to much strain on the system just using the mp3s/wavs during testing but sure I would like to actually generate the tracks on the fly that would be awesome.

Looking at the old mods its humbling how much these guys managed to achieve with such restrictions and primitive hardware. That's the thing is just the soundtrack to the game - its not going to be a demoscene submission so its not going to need that level of sophistication. So I am hopefully its a implementable idea. Even if it fails I will have learned a lot more so its all positive. Only thing I lose is time if this fails and I can go back to using a pre-recorded soundtrack.

Have to admit this is the most fun I have had on the project so far was messing with milkytracker and reviewing the mods. have been trying to find articles written about pro-tracker on sites like archive.org as I figure it must have been the subject of many an Amiga magazine article back in the day. Its weird there were not more books written about trackers. During that era there were so many books written on every subject under the sun to do with microcomputers. Just seems bizare this was not covered.

[zorg]

Maybe it was a niche, even if demo parties were vast; besides, the people there probably thought that all module playroutine implementations (since they liked to re-code it for themselves) were, in a way, ephemeral... maybe they felt that way about the formats themselves as well.

"Don't use this, a new, better one is coming out soon anyway!" - or something similar, said a line in a spec file about mods, i think... and then directly below, an editor who updated the spec wrote something along the lines of "Yeah, right...".

I agree, tracking back then was a completely different beast than how it is now. The limitations weren't artificial, at least, not with the original protracker on amiga. 4 hardware channels, that's it. (along with one supplied sample collection, if one didn't want to / couldn't record samples themselves) Of course, there were madmen later still, but that's another story altogether.

While i only looked for technical docs of the formats itself, and not articles for the layperson, i did find enough of the former to get started with implementing things myself. If you want, i can link them.

[Pangit]

That would be great. I would like to do something simple like just write a 12 tone line on the fly, that seems like a style that would be easiest to implement. I could use it for the AI scenes.

Dreamer / Flying cows wrote some of the most outstanding mods I have ever seen.

For those wondering what we are talking about..

https://www.youtube.com/watch?v=mt8Jt2-WjpM

This was done with 4 channels, on an Amiga. with 8 bit samples.

Small update:

have started writing the banking code for the game. At the moment its just a basic function that lets the game debit and credit the account and produce a balance.

In the c64 game neuromancer - each npc had a bank account and a bama id that was used in the game. What I want to be able to do is replicate this. So the logical way to do this would seem to be a class.

what I need to do is make account a class so that each npc in the game can have a bank account. So that's something to be getting on with today luckily Programming in lua seems to have everything I need to do that with a little playing.

[zorg]

Linking that scares the human.
That said, i prefer Ode to ProTracker myself, since that also tests for "interleaved" loops in more than one channel at the same time... pretty neat way to crash a player : )

Simpler, absolutely. Simple, not really.
Tough i did manage to code a 3-channel thing (among other stuff) that i linked a few times already...(press "2") I should finish turning that into a presentable project with a bit more cleaned up source...

Anyway, here are the resources i found:

• "master" list:
  ftp://ftp.modland.com/pub/documents/for ... mentation/ (despite it being ftp, just open it with your browser)
• what i found searching exact mod period values (first links to the second, still an interesting read):
  http://www.pouet.net/topic.php?which=8628
  http://resources.openmpt.org/documents/PTGenerator.c
• JStFFP wiki (most other modules are present as well, with (links to) specs as well):
  http://fileformats.archiveteam.org/wiki/Amiga_Module
• everything here beginning with "Load_":
  https://source.openmpt.org/browse/openm ... /soundlib/
• everything in this directory:
  https://github.com/schismtracker/schism ... master/fmt
• everything in here also:
  https://github.com/cmatsuoka/libxmp/tre ... rc/loaders