nesdev.com

This thread is created in case you want to share any assets for other to use in the upcoming Nesdev Compo 2016 (or anywhere else, if you grant permission).

Here's my contribution: a simple framework to create UNROMs games using cc65+neslib+famitone2. Still on the works, will update it with improvements as soon as they come. Includes shiru's Neslib and Tokumaru's lzss decompressor code and compression utilites.

Short documentation and a working example included.

You can use this as you like as long as you give credit to the involved authors (Shiru, Tokumaru, myself).

UPDATED [20160426]: Added support to put your music data for famitracker 2 in any switchable bank. A new example to showcase this feature has been included.

UPDATED [20161220]: Did some tiny fixes and added a new version of the compressor. I've ported Tokumaru's original VBscript compressor to freeBASIC. It *much* faster now, outputs source code if you need it, plus it is portable. Compiled Windows binary included.

_________________
http://www.mojontwins.com

Thanks. I was looking for a UxROM .cfg example file and yours appears to be a good one.

Regarding the contest: Is there any idea if 64KB will be the maximum ROM size again? It's not clear to me if that's a multicart limitation or a contest-imposed limitation.

The Action 53 mapper allows individual games to be 16K, 32K, 64K, 128K, or 256K. But the first two multicarts themselves have been 512K. And after about five contests (two past and three future), I plan to put together a multicart of the best 53 games that have appeared on previous multicarts (hence Action 53), and that might be limited to 2048K. So it's both: a contest-imposed limit to ensure games have enough fun-to-size ratio to be worthy of inclusion on the multicart.

64K is a nice size. I like the challenge to squeeze as much as you can in a limited space.

_________________
http://www.mojontwins.com

Will an entry be disqualified if it does not conform to this mapper specification? I am designing a UOROM game and 64KB is not going to be adequate for what I am doing.

I think there's also going to be an "anything goes" category, so you might be able to submit it there.

Freem is right. A 160K, 192K, 224K,* or 256K game may fit in the "anything goes" category even if it doesn't qualify for a prize or doesn't qualify for the larger prizes associated with a category that has a near-guaranteed slot on the multicart.


* For sizes not a power of two, I'd probably end up stuffing other games in the unused banks of your game.

I know this isn't really an asset, but it's a suggestion, and I refuse to not post it because I've spent days figuring this out. Like, I had to use a debugger and stuff.

text2data, which comes with famitone, has a function called output_close() in its source that looks like this:


Problem with it is, fclose() doesn't seem to set outfile to NULL, and the program is designed so that at exit, output_close is called. When it isn't NULL, fclose() tries to close...nothing. Bad. Errors. So make sure to change the function to...



It could be that no one else has ever had this problem, but I don't like wine or windows, so the existing binary is not an option for me. Also I converted the program from C++ to C, because other than some stylistic things, C++ doesn't seem to have much benefit, as the program is pure C. That's just me, though; for all I know it'd be better to use C++.

Any reason that can't be replaced with fcloseall()? (Or just removed entirely, since the CRT is supposed to close files when the program exits?)

You have an old copy. The source I have of famitone2 has that if.

As mentioned earlier, the 64KB is a limit to ensure its inclusion on the Action 53 volume associated with that compo. So it would be best to submit in the anything goes category which doesn't obligate its inclusion on the cartridge. But we may very well still be able to include it in the cartridge similar to how STREEMERZ was a larger (128KB UNROM) game included in volume 1. Bottom line is if you have a decent game you'd like included on the cartridge we'll do our best to include it within the hardware limits we set for ourselves (which we can always modify if deemed worth the cost).

_________________
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers

I'm assuming this can (kinda?) be like a question thread, so...this question is half curiosity, half wanting to showcase what code I'm working on (visuals are an unwritten story right now).

I'm designing my comp entry to work with "objects". These objects are just used for characters: the player and enemies, so that movement is always controlled properly. It's not completely necessary, but if the game engine is simple and boring then I'll probably lose interest quickly. The system works alright so far; haven't gone very in-depth yet, but it can probably handle creating multiple objects and running their respective routines at the least.

Does anyone think this could cause too big a change in speed, though? Running the objects' code shouldn't make a problem, but I'm not sure if the same can be said about their declaration. Finding an open spot, doing the math to transfer stuff to it, all that. I'm afraid that making everything too dynamic will make my game slow to play.

If it helps describe any, the game is probably going to have tiny (8x8, one tile) 'characters' so not much math with getting 16x16 characters on screen simply because that won't happen, and collision won't get more descriptive than "these two objectsare 8 pixels away from each other, let stuff happen".

I don't think I understand what you're asking. What does it mean to "declare" an object?

If it means "create", well then creating/deleting objects is a fast operation in most implementations. If you're storing objects as a list then creating/deleting is a constant time operation and nothing more than modifying a few pointers. Arrays require a search, but they really don't take up many more cycles than lists. And besides, how many objects are you going to be creating per frame? One? Two? I doubt very many. It's not like collision or movement code which happens every frame for every object.

True, spawning of enemies in a group can be spread out over several frames, one enemy per frame. But, say, the spread gun in Contra spawns five bullet objects in one frame.

Unless of course you're spamming the fire button to take advantage of the spawning pattern and unleashing an onslaught of damage in a tighter range.


As for spawning objects, I keep an updated list of any available slots and pull the first one from the list when it's time to spawn, then decrement the list. When something dies, I increment the list and write the destroyed object's number at the top.

It's more complicated, and less useful, to keep a list of the ones that are in use. But keeping a list of the available slots makes the spawning process pretty painless.