Author Topic: The new fork of HuC  (Read 14065 times)

spenoza

  • Hero Member
  • *****
  • Posts: 2751
Re: The new fork of HuC
« Reply #45 on: August 28, 2016, 06:07:38 AM »
Can Deflemask output to MIDI? The only reason I ask is that it is commonly used to craft "chiptunes" using classic samples. There are a surprising number of folks out there who work in chiptunes who only know how to use trackers, and having a path for them to get to Squirrel might be helpful.

'Course, if your friend is a legit musician, just generating something in MIDI is probably a lot easier.
<a href="http://www.pcedaisakusen.net/2/34/103/show-collection.htm" class="bbc_link" target="_blank">My meager PC Engine Collection so far.</a><br><a href="https://www.pcenginefx.com/forums/" class="bbc_link" target="_blank">PC Engine Software Bible</a><br><a href="http://www.racketboy.com/forum/" c

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #46 on: August 28, 2016, 10:34:15 AM »
3MLE is a MIDI piano roll program for free.  That's your best bet.

[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: The new fork of HuC
« Reply #47 on: August 29, 2016, 08:26:18 AM »

As for Squirrel, were your dudes having problems with it?   I really don't think you will find an easier way to get SFX and music going in your game.   The learning curve isn't as steep as some would think, especially now that there are so many easy to use DAWs that spit out MIDI which is so easy to convert to MML.


Squirrel is awesome for getting music and SFX into the game. It works great, at least from the coding side.

The biggest key has just been finding someone willing to actually make the music and SFX for us.
Hey, you.

Gredler

  • Guest
Re: The new fork of HuC
« Reply #48 on: August 29, 2016, 09:23:27 AM »
None of the guys I've tried to get involved seem to have given it a fighting chance, to be fair too. I am going to try using 3MLE to make something, and maybe it won't be so abrasive.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #49 on: August 29, 2016, 05:54:10 PM »



[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

nodtveidt

  • Guest
Re: The new fork of HuC
« Reply #50 on: August 30, 2016, 12:03:40 AM »
3MLE is the tool I use for MIDI->MML conversion. Works like a charm.

Gredler

  • Guest
Re: The new fork of HuC
« Reply #51 on: August 30, 2016, 05:50:35 AM »



Thanks for posting these here, but I've gone through them a bunch of times already - I really appreciate the detailed documentation between these and the readme.

3MLE is the tool I use for MIDI->MML conversion. Works like a charm.

I think this is where the disconnect is for myself and the two guys I've tried to get to use this workflow - authoring a halfway decent midi.

Where were you getting your midi's from?

Right now it seems like making the song straight up in 3mle is my best option, but I've looked into "anvil" and a few other programs to create midis with.

Arkhan

  • Hero Member
  • *****
  • Posts: 14142
  • Fuck Elmer.
    • Incessant Negativity Software
Re: The new fork of HuC
« Reply #52 on: August 30, 2016, 01:27:20 PM »
I use fruity loops.

Really though, making music requires you to ... know how to make... music.

Any music program from the last 25 years that isn't a shitheap can export a MIDI, basically.

[Fri 19:34]<nectarsis> been wanting to try that one for awhile now Ope
[Fri 19:33]<Opethian> l;ol huge dong

I'm a max level Forum Warrior.  I'm immortal.
If you're not ready to defend your claims, don't post em.

Gredler

  • Guest
Re: The new fork of HuC
« Reply #53 on: August 30, 2016, 02:59:07 PM »
Really though, making music requires you to ... know how to make... music.

Well, danmit. Where is the make music button?! Get your shit together!

Bonknuts

  • Hero Member
  • *****
  • Posts: 3292
Re: The new fork of HuC
« Reply #54 on: August 31, 2016, 06:46:43 PM »


 So one example of your large sprite, here I color coded a few areas to show some simple compression schemes you could apply directly in HuC. So while the PCE sprites cells are 16x16 in hardware, that doesn't mean you couldn't store them in smaller components like 8x8. Matter of fact, it's pretty easy to convert four 8x8 sprites into a single 16x16 when writing it to the hardware. But for the sake of simplicity and keeping the planar format, I chose 8px wide as the smallest width.

 So the simplest area of compression is of course just to omit blank 16x16 tiles. Those are marked in red (a group of 8x8 tiles making a 16x16 block). But obviously it doesn't always work with all sprites and sizes.

 The darker blue translucent areas show part of the image that can be represented as 2bit color instead of 4bit. That's an automatic 50% saving in those areas. Some of the transitioning areas of the bag in that image, have a limit of 7 colors and could be stored in 3bit format for a 25% savings per cell area (which I didn't highlight). Notice that I used 8x8 sectioning in the highlighting.

 The light blue and orange-ish areas show repeated data. Since this is planar, and a byte can represent 8px across, that data can be represent in numerous ways (RLE, bitmask for repeat patterns, etc). You can head sections of tile groups with headers, indicating which tiles are compressed and what type of decompression to use. I didn't highlight the whole image with all of columns of repeating 8px wide sections along 8x8 cells, but just enough to demonstrate.

Darker-Pink is similar to light blue areas, except the whole tile can be represented as a single row of 4bit 8x line and a simple RLE for the column length.

 The purple one is just an example of where a whole 16x16 cell is wasted to show a few pixels. The art could be changed slightly, and you'd save 128bytes right there.

 And just look at all those 8x8 green tiles (which are invisible pixels). Those could easily be represented as a single header byte (blank 8x8 tile). There are all sorts of compression schemes that you can throw at it, and having a diverse set of simple schemes can help out quite a bit. These types of schemes are also very fast to decompress to vram; many hucard games use compression schemes like these. If all you did was compress for blank 8x8 tiles and nothing else, you'd save 1,800 bytes alone in that pic (20% rom saving in space for the image).
 

Gredler

  • Guest
Re: The new fork of HuC
« Reply #55 on: August 31, 2016, 07:52:56 PM »
Thanks Bonknuts! I totally see the sloppiness in the edges cutting into 8x8 quadrants of larger sprites like this in many of my assets, if we implement a compression element that would need to be updated, but thats nbd if needed!

I should note that this image was a rough cutout for the web, the final sprite is cut into small enough peices that most of the green empty 8x8 quadrants are not accounted for.

Great to know about the color compression potential as well, if we can implement that the art can design around these restrictions for sure!
« Last Edit: August 31, 2016, 07:55:04 PM by Gredler »

esteban

  • Hero Member
  • *****
  • Posts: 24063
Re: The new fork of HuC
« Reply #56 on: August 31, 2016, 10:21:23 PM »


 So one example of your large sprite... you'd save 1,800 bytes alone in that pic (20% rom saving in space for the image).



I just wanted to say that even though I don't post often in technical threads, I absolutely love reading them, (especially when I can actually follow along semi-competently).

I appreciate the time you, elmer and others take to explain stuff.

:)
  |    | 

DarkKobold

  • Hero Member
  • *****
  • Posts: 1200
Re: The new fork of HuC
« Reply #57 on: September 13, 2016, 07:30:30 AM »
Getting back to work on Catastrophy, I've had a few thoughts on what would be helpful to have, as asm code.

First, there is no way to clear vram directly. A quick bit of asm that writes all zeros to vram would be helpful. cls() and reset_satb() don't actually empty the vram. (The main reason I need this is because I'm using 48pix high images in 64pix high sprites. Thus, I need to clear out the extra 0x80 of unused sprite space)

Second, an asm code for doing simple RLE decoding into vram would be awesome, assuming one could also add a separate program that compresses images into .bins, and tells you the % savings.

Finally, a program that helped you keep track of what is in vram would be awesome. Essentially, it'd just be a 32pixel wide listing from 0x0000 to 0x8000, so you could insert your images, and see how much you are using up. I know that sort of exists in emulators, but its hard to actually use.
Hey, you.

nodtveidt

  • Guest
Re: The new fork of HuC
« Reply #58 on: September 17, 2016, 07:07:54 PM »
I handle the last part by planning out a VRAM map in advance. It's not terribly difficult to do, and saves a lot of headache later.

Normal tiles use 0x10 VRAM words (#incchr).
Metatiles use 0x40 VRAM words (#inctile).
Sprites use 0x40 VRAM words per section (so a 32x64 sprite, 8 sections, is 0x200 VRAM words).
Each section of the BAT uses 0x400 VRAM words (so the default 64x32 BAT is 0x800 VRAM words).

The rest is just knowing where stuff goes. The BAT is typically at the start of VRAM, the SATB at the end. So you have all the space in between to do whatever you want with, though personally, I typically put the font right after the BAT.

Here's how Lucretia is set up, for example:

Code: [Select]
common graphics addresses
4600-49FF pause graphics
4A00-4FFF UI
5000-53FF player 1 sprites
5400-57FF player 2 sprites
5800-59FF projectiles
5A00-5BFF items

stage 1
3000-3BFF demon lamp
4000-42FF onigrass
4400-45FF oni-o-lantern
5C00-5FFF moon
6000-69FF birdie
6A00-71FF witch
7200-73FF powerup
7400-75FF tombstone
7600-79FF fence

touko

  • Hero Member
  • *****
  • Posts: 953
Re: The new fork of HuC
« Reply #59 on: September 17, 2016, 11:09:33 PM »
Quote
First, there is no way to clear vram directly.
Yes, there is a way, you can use VRAM->VRAM DMA.

Or in asm, a loop with some stx can do the job quickly .
« Last Edit: September 17, 2016, 11:11:24 PM by touko »