It is currently Sat Nov 18, 2017 10:12 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
Author Message
PostPosted: Fri Jun 06, 2014 6:20 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19226
Location: NE Indiana, USA (NTSC)
There are ways to make smoother animations even with the 32-pixel tiles. For example, Yoshi's Cookie for NES moves things 8 pixels at a time, which is smoother than 16. With 8-pixel movement, you'll have to avoid attribute clash somehow; that can be done by leaving an 8-pixel gap between tiles when moving them.


Top
 Profile  
 
PostPosted: Sat Jun 07, 2014 11:54 am 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
The attribute clash would be very very hard to overcome and it would surely come at a price at some point.

Redesigned the interface to look more like the Android game.


Attachments:
2048-4.png
2048-4.png [ 2.66 KiB | Viewed 1990 times ]
Top
 Profile  
 
PostPosted: Sat Jun 07, 2014 2:08 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19226
Location: NE Indiana, USA (NTSC)
raydempsey wrote:
The attribute clash would be very very hard to overcome and it would surely come at a price at some point.

Perhaps it might be easier if I demonstrate with an animated GIF.


Attachments:
File comment: My tile design, approximating the color scheme of https://gabrielecirulli.github.io/2048/
Palette is 0F371620 0F272620 0F382820 0F000F20

2048tiles.png
2048tiles.png [ 1.19 KiB | Viewed 1982 times ]
File comment: Moving things 8 pixels at a time and leaving an 8-pixel gap eliminates all attribute clash. The ">" signs denote blank spaces that have the same attribute as an adjacent tile.
2048gaps.gif
2048gaps.gif [ 5.3 KiB | Viewed 1982 times ]
Top
 Profile  
 
PostPosted: Sat Jun 07, 2014 7:12 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
tepples wrote:
raydempsey wrote:
The attribute clash would be very very hard to overcome and it would surely come at a price at some point.

Perhaps it might be easier if I demonstrate with an animated GIF.


This movement is unrealistic to the original game. In the GIF, the blocks are separating for a short time before coming together. Also, blocks travel at different velocities.


Top
 Profile  
 
PostPosted: Sat Jun 07, 2014 8:16 pm 
Offline
Formerly 43110
User avatar

Joined: Wed Feb 05, 2014 7:01 am
Posts: 313
Location: us-east
raydempsey wrote:
This movement is unrealistic to the original game.

The "original" is in a nearly unrestricted environment, There's almost certainly going to be compromises when porting to NES wherever it be small tile size, or additional gaps in the group movement. The question is which compromise is more desirable.

I personally believe that a tile size of 32x32 is a must have, and I'm intrigued in tepples's idea of showing a tile velocity of 8px per frame. Also the gaps actually do look more natural to me, especially once the tiles slide underneath when merging, but I'm wondering how to deal with the vblank time limitation. In the worst case, 208 nametable entries has to be updated in a frame. I guess the options are
  • threat the two nametables as a double buffered video frame and take two vblanks of times to update the other nametable
  • 60/50hz update by interleaving the tiles to be updated in some visually acceptable way
  • maybe some forced blank trickery can extend the vblank time to write 208 tiles?

Also I think there needs to be some sort of option switch (hidden or otherwise) that switches to the current color set and merging rule, to a color set and merging rule that matches the popular browser game. Because I actually like both.

EDIT: spelling


Last edited by JRoatch on Sat Jun 07, 2014 8:21 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sat Jun 07, 2014 8:19 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19226
Location: NE Indiana, USA (NTSC)
Updating half the grid in each frame should be acceptable. Consider Tetris for NES: it took about five frames to redraw the matrix after a line was cleared, and nobody gave a $#!+.


Top
 Profile  
 
PostPosted: Sat Jun 07, 2014 8:47 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
43110 wrote:
208 nametable entries has to be updated in a frame. I guess the options are[...]
There's a goofy option to increase the total bandwidth: fully unrolled loops of PLA/STA $2007 with stack haxery and using zeropage LDA $80/STA $2007/LDA $81[...] to store the entire tilemap. Since you're not using sprites (right?), this gives you enough off-screen time to schedule 324 writes during vblank, and you "only" need 312 ((16+2)×16 (nametables) +(4+2)×4 (attribute tables)) to update the entire display every frame. Using both techniques to update the entirety in a single vblank will take 272 bytes of RAM from zero page and stack, 1592-1800 (depending on how much is store in the stack and how much is stored in zero page) bytes of ROM and will complete the entire set of writes in 2144 cycles (out of ≈2260).


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 8:22 am 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
In my opinion, the animations should not be compromised for tile size in this game. I slowed down on an emulator the other version of the game being made that was posted and I found it had a lot of clunky, blinky animations.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 10:11 am 
Online
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 932
Perhaps you could use sprites (with same color of background) for animations of tiles movement? You could use background where sprites aren't needed, and then it might fit in 8 sprites per scanline

_________________
.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 12:13 pm 
Offline

Joined: Mon Sep 27, 2004 2:57 pm
Posts: 1248
I'm going to agree with the bigger 32x32 tile size, on the grounds that it seems a bit wasteful to have such a tiny playfield with such a huge amount of wasted space surrounding it. I'm sure you can dig up examples of wasted screen estate and nobody caring, but I still stand by opinion. I also like Tepples's animation, which is probably the most practical way to mitigate attribute clash without being able to have each tile be a sprite.

Tiles sliding at different velocities would be doable. If you used Tepples's animation as your basis, each tile would need to slide at 1/4 increments between its starting position and destination. Since the board is 4x4, there are only three options: The tile moves 3 spaces, 2 spaces, or only 1 space. This could easily be implemented with a lookup table.

To mitigate attribute clash like Tepples is doing, you assign a start-delay to each tile that has to move. If you press left for example, the leftmost movable tile starts its slide animation in the first frame, and any tiles to the right of it wait a frame. Then in the next frame, the next tile right starts moving, and the third tile (if any) waits until the next frame.

Of course, this means the board can vary between taking 4-6 animation steps before it's finished animating. If this is a problem, you can stretch the animation out by scaling the start delays so the animation always takes 6 steps. For instance, if two tiles can move, the first one starts in the first frame, and the second one waits two frames instead of one. If one tile can move, it can wait two frames or move immediately, up to you. Or you can "force" the animation to only be 4 steps by accepting player input after the 4th step, which can interrupt the animation (the tiles just jump to place, they wouldn't be too far off anyway) if the player chooses to move again before it finishes.

So there's lots of options for the bigger tile size to work, and I think that the only way we can tell if this is faithful to the gameplay or not is to try it out and see how it feels, though I'm pretty sure the game is still going to be 2048 regardless of what you guys bicker over. :P And even if all you guys disagree and we wind up with 5 different versions of this 2048 game, 'tis the spirit of mobile games anyway.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 5:57 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
Obviously it is a case of preference. Having my sprite-based game working well and having a familiar feel makes me believe that the sprite based approach is better. The smaller game block size is not bad. I can prove that there could be no larger game block background-tile based game that could be appropriated to accommodate smoother animations. It would be possible to use the occasional background sprite to aid in particular tasks to avoid the "too many sprites on a scanline" problem but even that is only a very minor problem.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 6:17 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6442
Location: UK (temporarily)
raydempsey wrote:
I can prove that there could be no larger game block background-tile based game that could be appropriated to accommodate smoother animations.
Given how you're a relatively recent newcomer to programming for the NES, I am very skeptical that any such "proof" exists.

In fact, I'd bet very good odds that the MMC3 or anything else with 1k banking could be used in combination with sprites to hide the attribute clash such that single-pixel accuracy were possible in the animations.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 7:43 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
If a person wants to use 9 background tiles (each game block 3x3), then there will need to be 3 leading sprites, 3 trailing sprites, and at least one sprite in the middle of each game block to show the score. That's 7 sprites to get the animation correct for one game block. There are scenarios where 12 game blocks would need to move simulaneously creating a demand for 84 sprites, which cannot happen. If that is not a proof I don't know what is. The next size smaller is 2x2 game blocks, which I achieved fluid animation using lots of sprites. Any 3x3 or higher background tile method cannot achieve the proper fluidity of animation.

Q.E.D.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 7:54 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19226
Location: NE Indiana, USA (NTSC)
Updating 208 tiles plus attributes in one vblank is possible with early-off or late-on.

In 32x32, it's possible to animate 12 or 16 tiles at once using scroll splits, where the background represents two columns of tiles moving at the same velocity and the sprites represent tiles that aren't moving at the same velocity. Do I need to illustrate this with another animation?

But in practice, did people who played Dr. Mario care that everything moved in 8-pixel jumps? If not, lack of "proper fluidity of animation" is no deal-killer.

I'm not trying to say that there's no place for a game using 16x16 pixel tiles. But something simulating desk accessories is probably better in a faux-windowed environment, like Windows 98 for NES, not in a traditional full-screen environment.


Top
 Profile  
 
PostPosted: Sun Jun 08, 2014 8:02 pm 
Offline
User avatar

Joined: Sat May 31, 2014 4:12 pm
Posts: 139
I think I would have to see the animation of a scroll split. I do believe that the animation can be compromised but I'm not willing to do that. Since I'm not familiar with a scroll split, it would be good to understand how it works.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 62 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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