I'm wondering about how the NES displays its graphical muscle. I've researched stuff online and read through it, but I'm wondering about one last thing: Nametables.
Basically, from what I've read, each 8x8 block in a NES nametable points to a location in the pattern table, which holds graphic memory. In addition, the nametable also has an attribute table which sets a certain color palette for each 16x16 block. They're linked up together like this:
(assuming 16 8x8 blocks)
Nametable, with A B C D = pointers to sprite data:
ABBB
CDCC
DDDD
DDDD
Attribute table, with 1 2 3 = pointers to color palette data, with < referencing value to the left, ^ above, and ' to the left and above:
1<2<
^'^'
3<3<
^'^'
So, in the example above, the blocks would be colored as so
1A 1B 2B 2B
1C 1D 2C 2C
3D 3D 3D 3D
3D 3D 3D 3D
Now, if I have this on a fixed screen - it works great! Because the NES resolution is 256x240 pixels. Now, how do these tables get adjusted for scrolling?
Because Nametable 0 can scroll into Nametable 1, and if you keep scrolling Nametable 0 will wrap around again. That I get. But what I don't get is how to scroll the attribute table wraps around as well. From what I've read online, the 16x16 blocks it assigns attributes for will cause color distortions on the edge tiles of the screen (as seen when you scroll left to right and vice-versa in SMB3).
The concern I have is that I understand how to scroll the nametables, but how do you scroll the attribute table? For intsance, if I have a green block on the left side of the screen, moving the screen to right should in theory cause the tiles to the right to be green as well until they move more into frame, to which they'll revert to their normal colors.
~~~~EDIT:
I do want to point out that I know about the scanlines, X and Y. This thought just ran through my mind.
Let's say I'm at scanline Y of 10. That means I'm reading 10 values into my nametables, horizontally. That would mean my first column is off of the screen, as it only has pixel width of 8. However, the color attribute stays, since it has width of 16.
Assuming the color attribute for the entire column is green, would I be correct in assuming that to the user, the first 6 pixels on the left of the screen would be colored green, and the rightmost 10 on the screen should be green as well?
So, would I be correct in my assumption that according to the screen, the left?
This site I'm sure you are already very, very familiar with. I will preface this by saying I never got to program for the NES, but I am very experienced with all the Gameboy hardware that was ever released and the NES shares many, ahh quirks with the GB/DMG. I going to bet that you either need to do one of a few things:
Don't scroll the attribute table. Make sure that your levels all have similiar color blocks along the direction you are moving. I'd guess that many first generation games did this.
Go ahead and allow limited attribute scrolling - just make sure that the areas where the changes are occuring are either partially color shared or sparce enough that the change isn't going to be noticable.
Get out your old skool atari 2600 timer and time a write to register $2006 in the end of HBlank update to get the color swap you need done, wait a few tics, then revert during the HBlank return period so that the left edge of the next line isn't affected. I have a feeling this is the solution used most often, but without a really good emulator and patience, it will be a pain in the butt. It will also eat a bit into your overall CPU usage as you have to wait around in interrupts on multiple scan lines to get your effect done.
I wish I had a more concrete answer for you, but this hopefully helps a bit. Thanks goodness the GB/DMG had a slightly more advanced scrolling system. :)
Both Super Mario Bros. 3 and Kirby's Adventure display coloring artifacts on the edge of the screen when you scroll. I believe both games set the bit that blanks the left 8 pixels of the screen, so 0-8 pixels will be affected on any one frame.
If I remember correctly, Kirby's Adventure always tries to put the color-glitched columns on the side of the screen that is scrolling off to make it less noticeable. I don't think these artifacts are preventable without switching to vertical mirroring, which introduces difficulties of its own.
Disclaimer: it's been like five years since I wrote any NES code.
Each nametable has its own attribute table, so there should be no graphical artifacts when scrolling from one nametable to another. The type of color glitching you are referring to is really only an issue if your game scrolls both vertically and horizontally. You only have two nametables, so scrolling both ways requires you to cannibalize the visible screen. There are various solutions to this problem, a great summary of which can be found in this nesdev post:
http://nesdev.parodius.com/bbs/viewtopic.php?p=58509#58509
This site may be of some help.
http://www.games4nintendo.com/nes/faq.php#4
(Search for "What's up with $2005/2006?" and begin reading around that area.)
It basically looks like its impossible to get it pixel perfect, however those are going to be the bits you're probably going to need to look into.
Wish I could be more help.
Each nametable has its own attribute table. If you limit your game world to just two screens, you'll only need to write the nametables and attribute tables once. The hard part comes when you try to make worlds larger than two screens. Super Mario Bros. 1 did this by scrolling to the right, wrapping around as necessary, and rendering the level one column of blocks at a time (16 pixels) just before that column came into view. I don't know how one would code this efficiently (keep in mind you only have a millisecond of vblank time).
Related
I got feeling retro and decided to write my favorite 8-bit computer game (Williams' Defender) on my first computer (Commodore PET 4032). All the code is being done in 6502 Assembly language. For those not familiar with the PET, all the graphics are character-based and to build games you move different characters around a 40 column x 25-row screen. This is very old tech - there are no sprites, no graphics layers, no ability to AND at the screen level, etc that we would be used to today.
I want the game to have multiple "laser beams" to be fired at the same time, and those laser beams might go on top of one another as they traverse the screen. Right now, as the beams move along the screen they store in memory what was underneath themselves and then replace what was underneath themselves as they move along to restore the background to its original state. The problem comes when a second laser goes on top of the first .. the first moves along and replaces the original background rather than leaving the second laser on top, then that second laser moves along and leaves artifacts of the first behind.
Is there a classic "light" algorithm or rule-set that allows multiple objects to move across one another such that the original proper things underneath are retained? I've tried different approaches (swapping backgrounds as things traverse, etc) but nothing seems to give me the correct result that I want.
It's certain an option to have each sprite keep a copy of whatever it overwrote, and have them erase themselves in the opposite order to that in which you drew them. That can't fail, but it assumes you have time for a full sprite draw and erase each frame.
You can also use a screen-sized buffer of 'is background' and 'is sprite' flags. Each time a sprite is drawn, mark its character locations as 'is sprite'. To erase all sprites iterate through the screen-sized buffer repainting the background anywhere that isn't marked 'is background'. You can keep upper and lower bounds of updated positions if iterating the whole 2000 potential slots is too great a cost.
You can also compare the differences between two such buffers to reduce flicker substantially supposing you have only one video buffer: paint the new sprites first, wherever they should go, noting them in the new buffer. Once all sprites are drawn, fill in background anywhere that the new buffer isn't marked 'is sprite' but the old is.
I would suggest:
Maintain a model of the game state that would allow you to redraw the entire screen at any time. This would include the positions and other state of all movable elements
As you update the game state between frames, accumulate a mask of all the cells that will need to be redrawn, because something in them changed or moved.
Iterate through the game elements in depth order from top to bottom, redrawing the parts of each element that are in the changed-cell mask
Remove any cell you draw from the changed-cell mask so it won't be rewritten by deeper elements.
The background will be last, and will redraw all remaining cells, leaving you with an empty mask ready for the next frame.
This procedure avoids any flicker that would be caused by undrawing anything you draw in a single frame.
Various indexing structures can be added to the changed cell mask to avoid unnecessary drawing work. What kinds of optimizations are appropriate here depend on your game. If the background is mostly static, for example, then it would be useful to add the coordinates of each changed cell to a list during the update, and then only check those cells during the background redraw. Or you could do this based on the previous positions of all movable elements... up 2 you.
If the majority of the scene changes in every frame, then you can skip the mask accumulation and just start with a full screen mask... although I think a PET might not be fast enough for such games.
Having never programmed for the Pet, I can't offer any specific advice about what you might try, but I can recommend keeping a copy of the current on-screen background in about 1k of RAM. That way, you can use that data to restore your background when removing the last "sprite" written to that tile. Unfortunately, that also requires you to keep your code and object data combined under 31k, unless you are programming this as a cartridge. Just a few thoughts, for what they're worth.
I'm writing a GUI in python, and using tkinter. I'm having trouble settling on an approach and need guidance.
Background: there's a server (not a webserver) that wants to present a lot of information to users, and let them edit some of it. It needs to send down information that a (relatvely) dumb python client uses to fill the window. Read only fields are Labels. The fields are generally single line Entry widgets, but some are multiline Text. There are some buttons, checkboxes and dropdowns. Asynchronously, the server can also update widgets, add them and remove them. In some cases, there are tables presented, to which the user needs to be able to add and remove rows.
The real problem is, the layout is dense and chaotic. The first row might contain 3 dropdown fields. The next might be 20 short Labels. The next might be a single long Entry field, and then I might want two tables (of different lengths) side by side,and then etc.. Based on user input of external factors, widgets, rows or entire tables might have to be dyamically added, or vanish.
I considered Grid, but it's unusable. A row with a single, long entry widgit in it, makes the first column wide and thereby pushes 12 of the 13 columns in the next row right off the window.
I considered Place, but this app will run on 3 different operating systems and users will be able to select their own fonts, so I'll never get the positions right. If there was some way to ask a widget how big it was, I'd happily use that to compute my own layouts in pixels, but it's apparently impossible to ask the size of a widget until AFTER it's been laid out by a geometry manager, which of course is too late.
So what I think I'm left with is Pack, where each row is its own frame, and some of those rows have tables (grids) in them. But I'm concerned that that means lots and lots of frames to render, and some of the users are on old, slow hardware. Plus... it looks just plain complex.
Am I missing a better way? Grid would be fine if I could convince it to stop trying to make columns line up. Place would be crunchy, but ok, if I could get the size of each widget in advance. Is placing within a lot of frames really the best I have?
Short answer, there's no better way; and the frame count isn't high enough to cause performance problems; so generating a frame per row is what works.
I have 4 (0-3 animation frames) different images of a coin animation with differet states of it spinning. I would like to make it look like its spinning by adding another 2 frames (4-5) to make it look like it spins. In current situation it looks like the coin spins 180 degrees and goes back to it's original position. I would like to flip vertically ONLY the 4th and 5th frame. How can i achieve that without making new redundant pngs?
I know making 2 new pngs is not a big deal in this case, but if i had more frames, and/or bigger sprites it could make a significant difference in future projects.
I was thinking you could make the animation flip horizontally when it reaches the last fame, however that would mean you would have to omit #4 and #5 to avoid duplicates, but it still would look odd because frame #3 would skip directly back to frame #0. I tried thinking of different orders the sprite frames could be placed in to clean this up, but all my solutions either result in duplicate frames, or ugly skips. Maybe you might be able to solve what I couldn't.
Unfortunately, it seems that though Godot supports play_backwards functionality for the animation_player node, there is no such feature when it comes to animated_sprite. Too bad, because this would likely solve your problem.
For now, I think your best bet is to do what you were trying to avoid.. flip the sprite images yourself and add them as animation frames, or make a separate animation containing the flipped sprites and have them switch back and forth after their last frames, respectively. It might be a lot of work for super large projects, but without some kind of play_backwards functionality for animated sprites, I don't think it's worth breaking your back trying to find a workaround this time.
Of course, if I am wrong, I would welcome any correction from the community.
Good luck.
this is one way to accomplish the task.
Inside the ready function of godot write
#used to store frame value
var frame = 0
Inside the function that your using that runs every frame write:
frame += 1
#resets the value representing the current frame
if frame > 5:
frame = 0
if frame == 4 || frame == 5:
#this should be whatever function you use to flip the sprite vetically
flip_h = true
else:
#this should be whatever function you se to flip the sprite horizontally
flip_h = false
You probably already know this because I recognize the udemy course this screenshot is from, as I am doing it right now, and this is explained later in the course (when adding spikeman enemy). But for those who don't know it can be solved by adding an AnimationPlayer and adding new animation track that deals with animation flip_h property of AnimatedSprite. Then you have to set flip_h on those last 2 duplicated frames.
You could use the signals to detect when the animation has finished
So I've started development on a rouge-like platformer. It would be difficult to explain exactly what it's like, but that doesn't matter. What does matter is how many sprites I need.
I have 4 classes and 4 races. (As of now, may add more later) Thief, Warrior, Wizard, and Archer. They all have different suits. As for race; Human, Elven, Reptillian, and Dwarven. Since the player can choose their race and class, do I need to make a sprite of every movement option for every combination of these? That would equal up to 16 different sprites. But since I'm adding movement, jumping, attacking, etc... Ugh I'm getting a headache just thinking about it, Help please?
you can do this with skeletal animation sprites.
You need to have a body sprite for each class and each race, but you can have a bone, and split the bone from bodies. Then you animate the bone, and allocate the proper body to it.
means that you design a run animation for bone, then when you need to play animation for any class and race, just apply the bone to specific sprites.
see this.
You will have to do a lot of drawing anyway, but what you can do is separate the classes and the races from the different movements. For exemple, draw a body without any outfit and any race specific attribut (assuming the dwarf and the elven have the same body size... ). Draw this body in all the positions you want. Then draw sprites with the only the heads of every characters, and then the outfits without anything int them.
Then, for each character, in the draw event, draw the standard body, then the character specific head, then the outfit.
The trick is to draw your body animations in such a way that the outfit and the head stay approximately the same during the movements, and the body does all the moving.
But in the end, all depends on the style you want. I would recommend my solution if you do some pixel art. Otherwise, if your characters are very detailed, you may want to use the skeletal animations as Ali Bahrami suggested.
i recommend creating a basic sprite for each race and then copying it and just adding the appropriate clothing / armour for each class.
I work for a ticketing agency and we print out tickets on our own ticket printer. I have been straight coding the ticket designs and storing the templates in a database. If we need a new field adding to a ticket I manually add it and use the arcane co-ordinate system to estimate where the fields should go and how much the other fields need to move by to accomodate new info.
We always planned to make this system automate with a simple (I stress the word simple) graphical editor. Basically we don't forsee tickets changing radically in shape any time soon, we have one size of ticket and the ticket printer firmware is super simple because it's more of an industrial machine, it has about 10 fonts and some really basic sizing interactions.
I need to make this editor display a rectangle of the dimensions by pixel of the tickets (can even be actual size) and have a resizable grid which can toggle between superimposition and invisibility on top of the ticket rectangle and represented by dots rather than lines.
Then I want to be able to represent fields by drawing rectangles filled with the letter "x" that show the maximum size of the field (to prevent overlaps). These fields should be selectable, draggable and droppable in a snap to grid fashion.
I've worked out the maths of it but I have no idea how to draw rectangles and then draw grids in layers and then put further rectangles full of 'x'es on top of those. I also don't really know much about changing drawn positions in accordance with mouse events. It's simply not something I've ever had to do.
All the tutorials I've seen so far presume that you already know a lot about using the draw objects and are seeking to extend a basic knowledge of these things. I just need pointing in the direction of a good tutorial in manipulating floating objects in a picturebox in the first place.
Any ideas?
For those of you in need of a guide to this unusual (at least those of us with a BIS background) field I would heartily endorse:
https://web.archive.org/web/20141230145656/http://bobpowell.net/faqmain.aspx
I am now happily drawing graphical interfaces and getting them to respond to control inputs with not too much hassle.