Page 2 of 2

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Wed Jun 21, 2017 7:49 am
by tepples
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Wed Jun 21, 2017 10:19 am
by FrankenGraphics
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)

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Wed Jun 21, 2017 2:16 pm
by Myask
^^^ 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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 12:57 am
by FrankenGraphics
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 1:02 am
by tokumaru
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 1:23 am
by FrankenGraphics
Oh yeah, and when you mention it, vertical scrolling would require offsets to the timing.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 3:27 am
by 8bitMicroGuy
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?

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 3:49 am
by FrankenGraphics
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 10:00 am
by lidnariq
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 10:15 am
by FrankenGraphics
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 10:36 am
by lidnariq
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 11:36 am
by FrankenGraphics
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.

Re: Drawing multiple sides of a building in a topdown RPG wo

Posted: Fri Jun 23, 2017 1:38 pm
by Myask
no need for the third; it'd line up to the tiles naturally.