Assets for the Nesdev Compo 2016

A place where you can keep others updated about your NES-related projects through screenshots, videos or information in general.

Moderator: Moderators

na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Assets for the Nesdev Compo 2016

Post by na_th_an »

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 477 times
Last edited by na_th_an on Wed Dec 21, 2016 3:10 am, edited 1 time in total.
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Assets for the Nesdev Compo 2016

Post by pubby »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Assets for the Nesdev Compo 2016

Post by tepples »

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.
na_th_an
Posts: 558
Joined: Mon May 27, 2013 9:40 am

Re: Assets for the Nesdev Compo 2016

Post by na_th_an »

64K is a nice size. I like the challenge to squeeze as much as you can in a limited space.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: Assets for the Nesdev Compo 2016

Post by mikejmoffitt »

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.
User avatar
freem
Posts: 176
Joined: Mon Oct 01, 2012 3:47 pm
Location: freemland (NTSC-U)
Contact:

Re: Assets for the Nesdev Compo 2016

Post by freem »

I think there's also going to be an "anything goes" category, so you might be able to submit it there.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Assets for the Nesdev Compo 2016

Post by tepples »

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.
User avatar
nicklausw
Posts: 376
Joined: Sat Jan 03, 2015 5:58 pm
Location: ...
Contact:

Re: Assets for the Nesdev Compo 2016

Post by nicklausw »

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: Select all

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: Select all

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++.
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: Assets for the Nesdev Compo 2016

Post by Joe »

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?)
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Assets for the Nesdev Compo 2016

Post by calima »

You have an old copy. The source I have of famitone2 has that if.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Re: Assets for the Nesdev Compo 2016

Post by infiniteneslives »

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).
If you're gonna play the Game Boy, you gotta learn to play it right. -Kenny Rogers
User avatar
nicklausw
Posts: 376
Joined: Sat Jan 03, 2015 5:58 pm
Location: ...
Contact:

Re: Assets for the Nesdev Compo 2016

Post by nicklausw »

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".
User avatar
pubby
Posts: 583
Joined: Thu Mar 31, 2016 11:15 am

Re: Assets for the Nesdev Compo 2016

Post by pubby »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Assets for the Nesdev Compo 2016

Post by tepples »

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.
User avatar
darryl.revok
Posts: 520
Joined: Sat Jul 25, 2015 1:22 pm

Re: Assets for the Nesdev Compo 2016

Post by darryl.revok »

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