It is currently Sun Nov 19, 2017 1:49 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 28 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Wed Jun 21, 2017 7:49 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19227
Location: NE Indiana, USA (NTSC)
FrankenGraphics wrote:
I associate cavalier projection with (mostly western?) MSDOS era CRPG:s.

What i meant with "classic JRPG" was a forced perspective where you see front and top of a cube, but not the sides.

That's similar to what this diagram on Wikimedia Commons refers to as "top-down oblique projection".

What I'm planning to do for a future project is show width and height at full size but depth at half size, as if the camera is pointed 26 degrees down. Then speed of movement along the depth axis is halved to compensate.

Image
To illustrate, I drew a crate


Thus 1 m wide is 16 pixels, as is 1 m tall, but 1 m deep is only 8 pixels.


Top
 Profile  
 
PostPosted: Wed Jun 21, 2017 10:19 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
Thanks for the link - very illustrative!

That's a very nice take on the top-down oblique perspective. I suppose you don't see that too often because of the 16x16 attribute grid (basically same with isometry or any skewed perspective).

Some solutions:
-2 subpalettes with dupe colours
-Common colour is floor colour
-1 subpalette for bright side, 1 for shadowy side and floor
-ExRAM
-Sprites (worst, since you spend both scanline bandwidth and an extra subpalette for something that still is on a 8x8px grid)

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Wed Jun 21, 2017 2:16 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
^^^ 16x8/8x16 attributes are fairly trivial to implement on a board, if you don't plan to scroll, since you can just switch CIRAM tables based on the LSbit (be it for X or Y) of the preceding NT fetch.

(Or, in software, raster-swapping the NT every 8 scanlines, but that'll crimp your cycles very fast.)
tepples wrote:
That's similar to what this diagram on Wikimedia Commons refers to as "top-down oblique projection".

Thanks, that helps a lot; I was looking for such, but your search-fu is better.


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 12:57 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
So with GTROM:s 2 pages of 4-screen nametables, you could theoretically software-swap them to provide a 16 x 8 (or finer, though it makes little sense) grid with easy free-directional scrolling; provided you have enough cycles to spare. Right? The ease of the scrolling might lend just a little bit to that end.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 1:02 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10112
Location: Rio de Janeiro - Brazil
Yes, but the hard part is timing the splits without IRQs. You'd have to run timed code most of the frame and end up with little time left for the bulk of the game logic.


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 1:23 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
Oh yeah, and when you mention it, vertical scrolling would require offsets to the timing.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 3:27 am 
Offline

Joined: Sun Mar 08, 2015 12:23 pm
Posts: 251
Location: Croatia
How about making one's own mapper where the mapper changes the attributes and the nametable and bankswitches by counting the scanlines like MMC5 does and then it has a table of scroll values that the IRQ code simply copies into the PPU_SCROLL registers from fixed mapper registers which are updated by the mapper?


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 3:49 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
Or if hardware accelerated on the pcb, can we decouple attribute page switching from nametable pageswitching on a hypothetical new mapper? It seems redundant/fidgety/restrictive to lock all of the nametable RAM on cart to timed toggling when all we want to toggle is the last 64 bytes of each NT. The fact that they're interleaved between nametables rather than sorted last or first in address space rules out the simplest form of masking, though. I have difficulties comprehending what should be used instead.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 10:00 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
Unfortunately, changing the way the PPU's attribute table is laid out is relatively I/O intensive, more-or-less requiring an FPGA. There are two conventions for making the attribute table have the same layout as the nametable, both targeting 8x8 attributes—MMC5 and Quietust's UNL-DripGame.

On the other hand, if you "just" want the ability to bankswitch the last 64 bytes of the nametable to something else, but retain the same 16x16 pixel granularity and packing ... well, there's no established mapper for that, but it is electrically simple.


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 10:15 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
It feels as if i'm missing a piece here. If toggling/bankswitching the last 64 bytes of a nametable is electrically simple, what's more complicated about doing it a fixed rate, via a timer set at 8 scanlines? This question assumes we don't need to reroute addresses.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 10:36 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
There's nothing hard about that. That's what Myask was referring to—it's easy to take note of ("latch") the address of the preceding nametable fetch and use that number to automatically bankswitch the attribute table.


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 11:36 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1012
Location: Gothenburg, Sweden
Oh, right. Thanks for clarifying that.

So basically the features would be
-Scanline based IRQ counter
-Attributes are switchable (rate selects x or y), so we can get 16x8 or 8x16
-a time offset at 0-7 steps so the attribute toggling can fine scroll

Whether it's CIRAM or ExRAM (like GTROM, etc) is arbitrary, even though the latter is of course more convenient and flexible, which is the whole purpose of a new pcb/mapper - to make pretty things work on a NES at a reasonable price.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Fri Jun 23, 2017 1:38 pm 
Offline
User avatar

Joined: Sat Jul 12, 2014 3:04 pm
Posts: 950
no need for the third; it'd line up to the tiles naturally.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


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