 |
nesdev.parodius.com
NES Development and Strangulation Records message boards
|
| View previous topic :: View next topic |
| Author |
Message |
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
 Posted: Fri Jul 29, 2005 10:08 am Post subject: |
 |
|
| Hey, tokumaru, I opened Final Fantasy 1 on Nintendulator, and I saw how they did that with the name table. I'm kindof thinking that will take alot of code if you know what I mean. Doesn't that take a function for each position, though? I don't know. Please explain. |
|
| Back to top |
|
 |
-tokumaru-
Guest
|
| Posted: Fri Jul 29, 2005 12:22 pm Post subject: |
|
|
| Celius wrote: | | Hey, tokumaru, I opened Final Fantasy 1 on Nintendulator, and I saw how they did that with the name table. I'm kindof thinking that will take alot of code if you know what I mean. Doesn't that take a function for each position, though? I don't know. Please explain. |
You dont have to think much about specifics in game programming. You must find the general case. You must think of a way to do 1 piece of code for your whole level.
You don't write different pieces of code for every screen of your level. You write code that is smart enough to know what it has to draw to the screen based on the player's position. You have a general drawing function that will keep track of the distance the player walked since the last frame and draw to the name tables the tiles that should come in as the player walks towards that direction. You'll copy the tiles from your level maps (wich are just big tables). That is the whole point of having a level map, so that you can calculate what you're going to copy from it based on player and camera positions and such.
This is called an engine. Your game engine must do a lot of things every frame:
-move the objects (player, enemies, etc.) based on input, phisics and A.I.
-check for collisions between objects (and background)
-draw to the screen whatever is new (objects or a new part of the level)
This is what I can think of right now, but I'm sure there is more to do. Keep in mind that 1 piece of code must do all these things, in order for you to have an engine, that will work no matter where in the level your player is.
Do things in a "hardcoded" way is really difficult, tedious and buggy. I used to do things like this when I first began programming games... It's actually logical, you start from the beginning of the level, just like the player, and then start to think "What can happen from here on?"... And then you program as you were playing the game.
But playing and programming a game are two very different things. Programming a game shoudn't be linar, like playing it is. You need an engine, that will keep track of everything that's happening in the game at all times, and decide what to do accordingly, regardless of where the player is and what is he/she doing.
If you do it linearly, you'll soon find yourself writing a lot of repeated (and extremely long!) code, wich will be very hard to mantain and even understand. But if you build an engine, updates and fixes to it are very easy, and drawing to the screen is not gonna be hard at all too.
The hardest thing in an engine like Mario or Sonic (platform engines) are the slopes. SMB1 doesn't have them, so it's not very hard to do. Phisics like in Sonic The Hedgehog are quite hard to do (I know, I'm trying to do something similar to it in the NES).
If your world is just made of square blocks it shouldn't be really hard to accomplish something soon. But since you're starting, I woudn't recommend a 4-way scroller, you should do it just horizontal, like SMB1, since it is a lot easier.
-tokumaru- |
|
| Back to top |
|
|
-tokumaru-
Guest
|
| Posted: Fri Jul 29, 2005 12:37 pm Post subject: |
|
|
Actually Celius, I think tou could think of your level map as a HUGE screen. A screen is 2-dimensional, right? So is your level map.
The problem is: the NES screen is much smaller than your level, so you must copy parts of it to the screen. The NES screen works like a "window" to the huge screen that your level is.
Now, as I told you before, the NES doesn't do anything automatically. So you can't just tell it to "show my level at position X", YOU have to make a copy of the section of the level you want to show.
OK, now you have copied the very begining of the level, and the player starts walking to the right. Soon, blocks will start to disppear to the left of the screen as the player walks, so you don't need them in the name tables anymore. What do you do? Well, the player is moving right and soon the stuff that left the screen through the left is going to return from the right!
You can't let this happen, so you draw the next parts of your level, little by little (column by column) as the player moves, over the parts that were just left behind.
I hope this makes any sense, because I really suck at explaining stuff through text, but I'm doing my best. |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 12:51 pm Post subject: |
|
|
| Are you sure scanlines wouldn't be easier? So if I do follow your method (Which I will do first) should I put the reset vector to the main engine? That's what the engine IS right? |
|
| Back to top |
|
|
-tokumaru-
Guest
|
| Posted: Fri Jul 29, 2005 1:44 pm Post subject: |
|
|
| Celius wrote: | | Are you sure scanlines wouldn't be easier? So if I do follow your method (Which I will do first) should I put the reset vector to the main engine? That's what the engine IS right? |
Well, you will end up using "triggers" (is this what you mean by "scanlines"? your term is a bit confusing) for some things, but I don't think it is a good technique to draw to the scrren.
Let me see if I get what you mean: When the player crosses a certain column (located at the middle of the second nemetable) you'll draw the next screen over the one you just left behind, right? If this is the case, I wouldn't recommend since you can't draw a whole screen in just one vblank. You will eventually get yourself drawing screens little bits at a time, even if you use triggers.
Then, the trigger method gets more complicated, since you'll have to divide your writes to the nametable in smaller pieces. And you must remember that you will most likely be doing other stuff during vblank, and you can't let your screen drawing routine eat all the avaliable time.
So, since you will have to divide your writes in little bits anyway, why not have your code draw these little bits as the player walks? Your writes to the screen won't take long (so you have time left for other things), and you must not worry about triggers. And you won't be doing any unnecessary drawing: in case the player decides to go back the way he/she came from you won't waste an entire screen you just drew.
Just keep a a count of how many pixels the player (or even better: the "camera") has moved. Every time this count is larger than your block size (tipically 8 or 16 pixels, like in my previous example), you draw a new column, and subtract 16 (or whatever is the size of your blocks) from the count variable. Keep doing this until you reach the end of the level. Same thing when the player goes back, but this time you subtract the pixels he/she walked, and everytime your counter goes below 0, you draw a column to the left and add 16 (or whateve...) to this count variable.
Now, about the reset vector, it shouldn't point to your main engine... I will most likely point to your title screen code, but that's up to you. In my stuff, I tend to group my code in blocks much like this:
- startup and title screen code
- player select/stage select/other setup things
- level startup (loads the first screen, show the level name, etc)
- main engine (wich will loop forever, until you reach the end of the level)(and is composed of many little functions like for controller reading and object handling, for example)
- level ending
- game ending
Or something like this. You usually don't want to turn the NES on and jump right to your main engine... You should show at least some kind of title screen before going into the game itself.
-tokumaru- |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 2:05 pm Post subject: |
|
|
I suppose then it's not such a good method. Well, with one of my projects, my character is going to move just like he does on Final Fantasy, when the camera keeps him in the middle ALL the time. So maybe a code like this would help:
showcolumn:
ldx up ;up key press
cpx #1
bne showcolumn
update:
ldy nextline ; bottom line for the upper screen
dey
bne update
That's probably the most unreliable dumb stupid code, but oh well. I still need to think of how this would work. I wonder how the nextline would work. Maybe have something like nextline=topline+32? You guys are probably looking at this saying, "Oh my gosh, you should just quit programming the NES before you get yourself hurt." But a function like that do you think would be good? |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 2:07 pm Post subject: |
|
|
Oh, oops, I think I made an error above. I don't know if you can say this:
ldx up
cpx #1
to make it say:
load x with up
check if up is pressed
Yeah, I think I screwed up. |
|
| Back to top |
|
|
Quietust
Joined: 19 Sep 2004
Posts: 1028
|
| Posted: Fri Jul 29, 2005 3:18 pm Post subject: |
|
|
| Did you know that you can edit your posts on this forum? |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 3:48 pm Post subject: |
|
|
| Yeah, but for whatever reason, I didn't. I was too lazy. |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 6:25 pm Post subject: |
|
|
| Okay tokumaru, so you say that Qbasic is a good language for making a level designer? I've been studying a little of it, and I don't know how it could open a .chr file. Do you know how? Could you post an example? |
|
| Back to top |
|
|
tepples
Joined: 19 Sep 2004
Posts: 6106
Location: NE Indiana, USA (NTSC)
|
| Posted: Fri Jul 29, 2005 8:57 pm Post subject: |
|
|
| The first .chr editor I made was in Qbasic. The first ROM hack I ever did was replacing the font in Super Mario Bros. Try looking for functions to read and write files. |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 9:21 pm Post subject: |
|
|
| Oh my, I feel dumb now. Well, I guess it has to be possible, then. I will go do that then. By the way, in Final Fantasy 2, they loaded their portraits as sprites. So would that mean that there's actually like 16 sprites making up their picture? And along with that, whenever I use sprite DMA, I can never seem to load multiple sprites. I can load the first one, but not any after that. Is there something I'm missing out on? |
|
| Back to top |
|
|
tokumaru
Joined: 12 Feb 2005
Posts: 3584
Location: Rio de Janeiro - Brazil
|
| Posted: Fri Jul 29, 2005 10:16 pm Post subject: |
|
|
| Celius wrote: |
showcolumn:
ldx up ;up key press
cpx #1
bne showcolumn
update:
ldy nextline ; bottom line for the upper screen
dey
bne update
That's probably the most unreliable dumb stupid code, but oh well. I still need to think of how this would work. I wonder how the nextline would work. Maybe have something like nextline=topline+32? You guys are probably looking at this saying, "Oh my gosh, you should just quit programming the NES before you get yourself hurt." But a function like that do you think would be good? |
Hum... supposing you could read the state of the "up" key (I don't think it can be done quite as you described it), I wouldn't recommend this kind of code.
You see, you're doing exacly the opposite of what I told you should do. You are thinking about a very specific case: when the player goes up. So lets say the player is standing over there, at the middle of the screen, and he/she can do nothing but go up.
If you think about it, the player can't even go up, since you're not reading any data from the controllers.
Also, you can't stop your game waiting for player input. If you do that, the enemies won't move, unless the player moves too. You can't have a loop that waits for user input! You must have a main loop (engine) that every frame checks if the player is pressing anything on the controller, if he/she isn't, just don't move the player, but you still have to animate enemies, update sound data, palette, etc., and that's why you can't lock up the game waiting for the user to press something. The game has to go on wether the player is pressing anything or not.
-tokumaru- |
|
| Back to top |
|
|
tokumaru
Joined: 12 Feb 2005
Posts: 3584
Location: Rio de Janeiro - Brazil
|
| Posted: Fri Jul 29, 2005 10:37 pm Post subject: |
|
|
| Celius wrote: | | Okay tokumaru, so you say that Qbasic is a good language for making a level designer? I've been studying a little of it, and I don't know how it could open a .chr file. Do you know how? Could you post an example? |
Yes, you can use qbasic to load CHR files, but I don't see why would you need this... (unless you draw your tiles using a tile editor) So, I guess you do use a tile editor...
Well, you must have read about the format of the NES tile before, since every NES document describes it:
| Code: |
VRAM Contents of Colour
Addr Pattern Table Result
------ --------------- --------
$0000: %00010000 = $10 --+ ...1.... Periods are used to
.. %00000000 = $00 | ..2.2... represent colour 0.
.. %01000100 = $44 | .3...3.. Numbers represent
.. %00000000 = $00 +-- Bit 0 2.....2. the actual palette
.. %11111110 = $FE | 1111111. colour #.
.. %00000000 = $00 | 2.....2.
.. %10000010 = $82 | 3.....3.
$0007: %00000000 = $00 --+ ........
$0008: %00000000 = $00 --+
.. %00101000 = $28 |
.. %01000100 = $44 |
.. %10000010 = $82 +-- Bit 1
.. %00000000 = $00 |
.. %10000010 = $82 |
.. %10000010 = $82 |
$000F: %00000000 = $00 --+
|
So, each tile is made of 16 bytes, arranged as you see above. I can't write a program to decode this tiles for you, but I have written a program in the past that does the opposite: it converts bmp files to the NES format. You can find it in the www.nesdev.com page, under the graphic tools section. The name is "BMP2NES", it says it's by 7h1460, as I used to carry that stupid name. This program was written in qbasic, so if you look at the source (included in the zip) carefully you can just revert the process.
Also, I think there is a tile editing tool written in qbasic as well, so you might take a look at it too.
But seriously Celius, if you don't know how to handle the sprite moving and the level drawing in the NES yet, you shoudn't be thinking about complex levels editor just yet. I sugest you get a little more confortable with the platform before you get into such serious projects. Make a few demos, learn how the platform works. Because if you don't know that, it will be very difficult to come up with a usefull level format and/or editor.
-tokumaru- |
|
| Back to top |
|
|
Celius
Joined: 05 Jun 2005
Posts: 1941
Location: Minneapolis, Minnesota, United States
|
| Posted: Fri Jul 29, 2005 10:44 pm Post subject: |
|
|
| Uh, that wasn't the full code by the way. that was a PEICE. I will create a good Qbasic program that designs levels, and I will have to think of a way to have my code incbin it. I'm not sure of how that one will work. I will be frustrated for months trying to get it to work. Well, I'll think of a good scrolling code, or go to someone for help. When saving the level data in my level editor, what kind of file should I save it as? |
|
| Back to top |
|
|
|
|
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 vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
