It is currently Sun Dec 17, 2017 7:13 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 18 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Framework code WIP
PostPosted: Wed Feb 05, 2014 7:11 am 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Edit: Changed thread title for updated code in a new post in this thread. What follows in this post is the framework code I had last year.

Hello,
I have been working on a metroidvania style game for the 2014 compo for the past 3 weeks. So today I decided to attach what I have so far. It's going to use the A53 mapper solely for the mirroring switch. I intend to restrict it to 32k for the possibility that all mapper register selecting be done in the multicart menu.

Little things I'm happy about accomplishing:
  • TV system detection in the second "bit $2002" wait.
  • A PPU uploading system in vblank that works with five 32-byte buffers.
  • A simple callback from nmi, so that I can also have a background process for level unpacking.
  • Modified famitone2 to support Dendy.
  • An interesting system function I coded yesterday. (try holding 'A')

Things that I hoped to have done by this time:
  • progressive metatile loading to nametables via the PPU uploading thing I made
  • pattern shift rotation for fake parallax.
  • main character jumping from a flat ground.

I'm aiming to get this done in time for the compo, but it's doubtful, seeing as I may not have the graphic and music skills needed, and 1 out of 3 months have already passed. I thought about going for a simpler idea, but that may not be best, as I have a clear general design for this game already. Category 3 or next compo are options for going over the time budget.

Thanks to the editors of nesdev wiki, and everyone involved in unregistered's thread (it was quite a read). I'll continue to post updates to this thread, and I'll rename the topic when this game is finally named.


Attachments:
File comment: Tech demo 1
2014-02-05_untitled.nes [32.02 KiB]
Downloaded 387 times


Last edited by JRoatch on Tue May 12, 2015 8:59 am, edited 1 time in total.
Top
 Profile  
 
PostPosted: Wed Feb 05, 2014 10:28 am 
Offline

Joined: Sun Apr 04, 2010 4:28 pm
Posts: 91
The stack overflow display is a neat idea. I have one byte at $01BF that I check once a frame for a stack overflow (Stack shouldn't go deeper than $01C0), but I hadn't thought of displaying the stack on error. You could expand this, I assume, for a debug view - the ability to display any page of memory at any time.

I can see a line and can make it scroll to the right. Should anything else be happening?


Top
 Profile  
 
PostPosted: Wed Feb 05, 2014 11:07 am 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Maybe as a septate debugger, because the stack overflow routine is currently starving for memory (it only uses $00ff which is reserved for "sta $ff" breakpoints). It also happens to fit in the last page.

pops wrote:
Should anything else be happening?


Nope, the text for tv system detection is all there is, maybe in a few days I'll get scrolling backgrounds or something.


Top
 Profile  
 
PostPosted: Wed Feb 05, 2014 12:40 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
Should it display this icon if a stack overflow occurs? Image


Top
 Profile  
 
PostPosted: Wed Feb 05, 2014 2:29 pm 
Offline

Joined: Sun Apr 04, 2010 4:28 pm
Posts: 91
tepples wrote:
Image

I laughed out loud. And promptly added it to my game.

That said, if he's limiting the game to 32k, he might not have 64 bytes to spare for the icon.


Attachments:
Screen Shot 2014-02-05 at 3.22.05 PM.png
Screen Shot 2014-02-05 at 3.22.05 PM.png [ 7.08 KiB | Viewed 5002 times ]
Top
 Profile  
 
PostPosted: Tue Feb 11, 2014 6:12 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Still haven't got scrolling figured out completely. Maybe I'm giving myself to much requirements for it. Anyway here's what was done this time:
  • A silly loss-full font compression that saves 30% compared to black and white
  • A bit more complex of a process manager, that can have multiple cancelable stacked processes.
  • At least defined some sort of meta-tile scheme.
  • Just for this demo a tile parallax effect. (still needs to be worked on)

The demo simply scrolls down, pressing down scrolls faster.

pops wrote:
That said, if he's limiting the game to 32k, he might not have 64 bytes to spare for the icon.

I'll drop the whole routine first if I really need the extra 64 bytes. In any case I added a bomb icon, reminiscent of old Macintosh crashes, in my font. I think that the stackoverflow icon represents the website more then it does the concept.


Attachments:
File comment: Tech demo 2
2014-02-11_untitled.nes [32.02 KiB]
Downloaded 198 times
Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 2:39 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7319
Location: Chexbres, VD, Switzerland
If this is for the contest : Aren't you supposed to keep everything private until April 1st (except for category 3 maybe) ?


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 7:36 am 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Bregalad wrote:
If this is for the contest : Aren't you supposed to keep everything private until April 1st (except for category 3 maybe) ?

I didn't think there was a problem. I didn't see a rule forbidding it and then there was this:

infiniteneslives in 2014 NESDev Compo - Guidelines/Rules wrote:
Punch wrote:
Is there any problem to release work in progress ROM images to the public during the course of the competition?
I don't see any issue with sharing progress while the competition is going.


I'm also too used to another compo's guideline of "keeping an informative and interesting account of their development". and just like in that compo I'll most likely go over time anyway, forcing this to be submitted as category 3.


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 7:54 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5899
Location: Canada
Unless entries are to be submitted anonymously for impartial judging, I can't think of any reason to keep them private before the competition, except that it's fun to surprise people.


Top
 Profile  
 
PostPosted: Wed Feb 12, 2014 9:27 am 
Offline
Formerly WhatULive4
User avatar

Joined: Fri Oct 30, 2009 4:43 am
Posts: 339
There is no rule about posting. People do it in irc, I don't see why a forum would be any different. Some people don't have others to test their work.


Top
 Profile  
 
PostPosted: Mon Feb 24, 2014 1:38 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
I'm shelving this for a month as I'm going for a simpler game in the contest.

Attached is the current source code for those who are interested. system.s is the most interesting file I think.
The scene is unchanged from last post but there are a few changes source wise.
  • The ppu uploader can now write individual tiles/bytes
  • the process manager is now a simpler task list, (but each task is still theoretically cancelable by a higher task).
  • A 50 byte subroutine to fill chr-ram with bad apple/game genie like tiles


Attachments:
File comment: Tech demo source
2014-02-21_untitled.zip [31.29 KiB]
Downloaded 199 times
Top
 Profile  
 
 Post subject: Re: Framework code WIP
PostPosted: Tue May 12, 2015 9:40 am 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
Ok I was split between posting in this thread or in controller test.
I decided this thread because the majority of the source was working towards the eventual metroidvania project.

Major accomplishments:

Things todo soon:
  • Documentation. It's so lacking now it hurts.
  • A APU system that can hopefully mix together different music and sfx streams.
  • reimplement progressive CHR loading under the new event loop
  • Modify PPU uploading system to read from PPU as well, so that CHR RAM can be used for general ram storage
  • More use of the data stack. Especially for 16-bit physics computation.
  • Figure out how to represent Nerdtracker2 steams more compactly.
  • Interbank calls

Questions:
For reading the new controller state, does it make sense take The bitwise Majority of the previous state and two new reads?
My module convention it a mess. How should it be improved? lazy65?


Attachments:
2015-05-12_framework.zip [46.62 KiB]
Downloaded 111 times
Top
 Profile  
 
 Post subject: Re: Framework code WIP
PostPosted: Tue May 12, 2015 10:10 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19353
Location: NE Indiana, USA (NTSC)
I considered bitwise majority of previous, new read #1, and new read #2, but that can cause spurious Up+Down presses.

Hold Up + Left, then within a frame move to Down + Left.

Previous: Up + Left
Read #1: Down + Left
Read #2: Bit deletion prior to Up makes it appear as Up + Down
Result: Majority for Up, majority for Down, majority for Left

So instead, I just go with new read #1 if new read #1 == new read #2 else previous.


Top
 Profile  
 
 Post subject: Re: Framework code WIP
PostPosted: Tue May 12, 2015 4:22 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
I'm actually OK with the result of that case. because if the next frame is also Down+Left, the net effect is that only the Up button transition was delayed for a frame.

The problem I'm concerned about is that a single bit accidentally toggles for 2 consecutive frames, resulting in a random pause glitch or some phantom right button presses. The disadvantage of this bitwise majority over "if read1 == read2 then state = read" is, as you pointed out, the button transitions are not synchronized and can cause issues for naive game logic failing to account for Up+Down, etc. Also I'm hoping there won't be a noticeable pattern of transition lags, like somehow the Right button will feel less reliable then the A button.

If I wanted to also deal with the problem of failing to catch a single frame press and release, I should probably just do a majority of three reads.


Top
 Profile  
 
 Post subject: Re: Framework code WIP
PostPosted: Sun Nov 08, 2015 8:19 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
I do not have a comprehensive code set now, but I wanted to say a bit about the new goal I've been aiming for so far. For now I'll name this project "NES Toy Box", and I hope someday I can get the code to a state were I can start soliciting contributions.

It started with the todo list of coredump v1.2 and grew into an idea that I mentioned at the beginning of this year, a collection tech demos and toys with fun and interesting menu navigation. controller test was kind of the first toy I imagined for this. Then GTROM was announced I've been targeting that ever since. In the past weeks, the desire to do this project has been growing stronger, especially now since Tepples is working on the 240p test suite and KHAN Games released The Incident.

A few conventions I've came up with for this:
  • Extensive use of a Forth like data stack (use of the Zeropage,X and Indirect,X opcodes) for parameter input/output.
  • FamicomBox inspired header (16 bytes title, 2 bytes checksum, 8 bytes reset stub, 6 bytes vectors)
  • NMI and IRQ located at $07f8 and $07fc respectively. Chosen to be power of two aligned, and to be compatible with blargg's romless format as long as the locations are prefixed with NOP and JMP opcodes.

The header checksum is verified by summing every 2 byte word in the 32KiB bank and checking if the sum is zero. The 8 byte reset stub is like the classical 10 byte reset stub but without setting the stack pointer.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 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