It is currently Sat Oct 21, 2017 3:35 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Mon Apr 25, 2016 11:37 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
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 69 times

_________________
http://www.mojontwins.com


Last edited by na_th_an on Wed Dec 21, 2016 3:10 am, edited 1 time in total.
Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 11:53 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 197
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.


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 12:07 pm 
Offline

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


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 2:08 pm 
Offline

Joined: Mon May 27, 2013 9:40 am
Posts: 351
64K is a nice size. I like the challenge to squeeze as much as you can in a limited space.

_________________
http://www.mojontwins.com


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 6:31 pm 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1306
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.


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 6:36 pm 
Offline
User avatar

Joined: Mon Oct 01, 2012 3:47 pm
Posts: 152
Location: freemland (NTSC-U)
I think there's also going to be an "anything goes" category, so you might be able to submit it there.


Top
 Profile  
 
PostPosted: Tue Apr 26, 2016 6:37 pm 
Offline

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


Top
 Profile  
 
PostPosted: Thu Apr 28, 2016 6:04 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
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++.


Top
 Profile  
 
PostPosted: Thu Apr 28, 2016 8:02 pm 
Offline

Joined: Mon Apr 01, 2013 11:17 pm
Posts: 437
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?)


Top
 Profile  
 
PostPosted: Fri Apr 29, 2016 1:33 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 558
You have an old copy. The source I have of famitone2 has that if.


Top
 Profile  
 
PostPosted: Fri Apr 29, 2016 9:13 am 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 1905
Location: WhereverIparkIt, USA
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


Top
 Profile  
 
PostPosted: Sat May 14, 2016 5:22 pm 
Offline
User avatar

Joined: Sat Jan 03, 2015 5:58 pm
Posts: 367
Location: ...
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".


Top
 Profile  
 
PostPosted: Sat May 14, 2016 7:59 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 197
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.


Top
 Profile  
 
PostPosted: Sat May 14, 2016 10:27 pm 
Offline

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


Top
 Profile  
 
PostPosted: Sat May 14, 2016 11:23 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 26 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group