nesdev.com
http://forums.nesdev.com/

Assets for the Nesdev Compo 2016
http://forums.nesdev.com/viewtopic.php?f=22&t=14144
Page 1 of 2

Author:  na_th_an [ Mon Apr 25, 2016 11:37 pm ]
Post subject:  Assets for the Nesdev Compo 2016

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.

Attachments:
neslib-unrom--20161220a.zip [441.49 KiB]
Downloaded 88 times

Author:  pubby [ Tue Apr 26, 2016 11:53 am ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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.

Author:  tepples [ Tue Apr 26, 2016 12:07 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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.

Author:  na_th_an [ Tue Apr 26, 2016 2:08 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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

Author:  mikejmoffitt [ Tue Apr 26, 2016 6:31 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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.

Author:  freem [ Tue Apr 26, 2016 6:36 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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

Author:  tepples [ Tue Apr 26, 2016 6:37 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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.

Author:  nicklausw [ Thu Apr 28, 2016 6:04 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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:
Code:
void output_close(void)
{
    if(outfile) fclose(outfile);
}


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...

Code:
void output_close(void)
{
    if(outfile) fclose(outfile);
    outfile = NULL;
}


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++.

Author:  Joe [ Thu Apr 28, 2016 8:02 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

nicklausw wrote:
the program is designed so that at exit, output_close is called.

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?)

Author:  calima [ Fri Apr 29, 2016 1:33 am ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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

Author:  infiniteneslives [ Fri Apr 29, 2016 9:13 am ]
Post subject:  Re: Assets for the Nesdev Compo 2016

mikejmoffitt wrote:
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.

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).

Author:  nicklausw [ Sat May 14, 2016 5:22 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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".

Author:  pubby [ Sat May 14, 2016 7:59 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

nicklausw wrote:
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.

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.

Author:  tepples [ Sat May 14, 2016 10:27 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

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.

Author:  darryl.revok [ Sat May 14, 2016 11:23 pm ]
Post subject:  Re: Assets for the Nesdev Compo 2016

tepples wrote:
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.

Page 1 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/