So I started this topic because I heard about XOR filling in the "Polygon Filling..." thread, and I couldn't quite wrap my mind around it. I tried finding info with google, and there's really little info about it, so please don't post a link to just f-ing google it. I basically understand that you go through column by column and do something with EOR, haha. Could someone fill in the gaps (Slight pun intended)? Please, and thanks in advance.
EDIT: Actually, I read a little more about it and it clicked. So nevermind... Thanks anyways.
Here's a good page with info:
http://student.kuleuven.be/~m0216922/CG/xortexture.html
Even if you don't need it anymore, it may help others.
Thanks, but I think this is something different. The XOR filling technique I'm referring to is one where you just fill a wireframe polygon in with solid color. This seems to be something else. Thanks though.
Celius, I too couldn't find much info on it... Is this that technique where you define the outlines of the polygons and then to render them you go through the scanline switching the state from filled to empty and vice versa when an edge is encountered? Sounds painfully slow for the NES!
Yes, you start out with an outline of a polygon, but the lines have to be drawn a certain way as to not screw things up. Doynax explained it in the "Polygon Filling" thread, and at first I was a little confused. In C, which I only understand a little of, he wrote it like this:
doynax wrote:
Code:
for(x = 0; x < 256; ++x) {
pixel acc = 0;
for(y = 0; y < 240; ++y) {
acc ^= screen[x][y];
screen[x][y] = acc;
}
}
Basically you run through the screen column by column, with "Acc" starting out as 0 at the beggining of each column. You go down one pixel at a time, and XOR the pixels there with Acc, and make Acc equal to that value. This will basically take 2 pixels in a column and fill in the space between them. It's a great and simple method a lot of the time. It doesn't take that long, because we knock out 8 columns of pixels at once. And I have a loop that walks through tile by tile. If a tile is blank but between two pixels, I just have a solid tile I stick in there, so it saves time/CHR space.
I see... but you said you were having trouble drawing more than one polygon, right? I guess the only way is to draw one polygon at a time, on top of the others. Of course this would slow things down a lot.
Another option would be to have a few (as many as the amount of polygons in a scene) accumulators and bitmasks, and work on all of them at the same time as you work your way through the screen pixels. But it still sounds too slow... I wonder what exact method Doynax used in his demos.
Yeah, I wish I could get a hold of doynax; it's obvious he knows how to do this efficiently. The one-at-a-time polygon thing seems incredibly tedious. Here's what I'm thinking though.
Since this is the NES, I'm working with 2 bitplanes. I won't take one wireframe bitmap and fill it in; I'll have 2 bitmaps; one for each plane. Also, the polygons that are touching that will be the same color don't need to be separate; they can be one polygon by itself. So I'll walk through these bitmaps for each plane, and I'll have myself multi colored polygons! Oh, yay, I'm gonna go start coding I'm excited.
Celius wrote:
I'll have 2 bitmaps; one for each plane.
That's a very good idea! So, in order to use the 3rd color both planes must be set then? I guess it could work.
Are you planning on using this for real 3D or just for polygonal animation like in Another World/Out of This World? Whichever it is, you're gonna need a separate tool to prepare all the data, no?
I'm doing an Out of this World type of thing, at least I think what I'm doing is like that. I'm basically doing this for CG sequences. I don't really think I'm ready to try code game logic + real time 3D along side all these complications =).
I figure I'll make some sort of application to make my life easier. I at the very least have MS paint to plan out each frame in. I still need to come up with a space-efficient format for storing these frames. I figure in each frame there'll be similar elements, so it won't be too hard. I still am unsure of what the frame rate will be, but I hope for it to be 10+ FPS. While Doynax has successfully done this + 3D calculations at incredible speeds, I plan for a very space-efficient NTSC engine that doesn't use illegal opcodes. This sacrifices speed, obviously.
The other thing is that I might want to apply some dithering effects to have a total of 16 "colors". This would be a little harder, so for now I'll just stick to 4.
Celius wrote:
The other thing is that I might want to apply some dithering effects to have a total of 16 "colors".
Oh yeah, that'd be essential for producing decent videos. I have no idea how that could be implemented fast enough.
Well my sequences wouldn't be very complex, as there are only 256 tiles to deal with. But good news! I've got the 4 color polygon frame draw working! So now all I have to do is come up with an efficient way to store my frames and now add frame change capabilities. Other good news is that polygon filling goes by much faster than line drawing, which is ironic.
The hard part will then be making the frames. I definitely need some sort of application/conversion program for this. I'm not sure how I'll go about this, but once I have a movie, I'll definitely be posting it up!
Celius wrote:
Well my sequences wouldn't be very complex, as there are only 256 tiles to deal with.
I was thinking about that. How will you arrange the 256 tiles? It woldn't look good if the movie played inside a square, video looks better when the "screen" is wider than it's tall, which is why widescreen is so popular nowadays.
Also, if you're gonna use all background tiles on the video, all the area around the video should be hidden with blank palettes. This does introduce the problem that color 0 must not be changed while the video plays or the border would change colors also, and that might keep you from selecting the best 4 colors for each scene.
Personally, I'd have the video screen use 18x14 tiles, which would make it a bit wider and would leave 4 tiles available for use on the border, so that the video could change all 4 colors freely.
Quote:
So now all I have to do is come up with an efficient way to store my frames
The frames should just be a collection of polygons, that is, a bunch of points to be connected by lines. Inside such a small screen, two bytes would be enough for defining each point. Also because of the small size, higher values could be used as flags to indicate the end of a polygon, end of a frame, a palette change, and so on. something like this:
Code:
ADDR DATA
$00: 28, 8 (point)
$02: 11, 50 (point)
$04: 58, 48 (point)
$06: [end of polygon]
$07: [end of plane]
$08: [end of frame]
This should be anough to draw a simple frame, with a triangle in plane 0. It seems pretty compact to me! Also, to make things very compact, you should somehow take advantage of temporal redundancy. Like, if a scene has a type of background there should be a way to use the same data in all the frames that use it. This doesn't sound so simple though, because you'd have to draw things on top of other things, so you might at first just go with the independent frames.
Anyway, it would be a good idea to keep each frame under 256 bytes, so that they can be easily (and quickly!) read with indirect indexed addressing. The main timeline could be just a bunch of pointers to frames, so that they can be reused. Although that would be a waste if there weren't many repeated frames... unless there was a frame count for every pointer, indicating how many frames to play from that point on.
Well, let the complicated stuff for later. Just start out simple and get your demo running. I'm sure you'll have some good ideas on the way.
Quote:
and now add frame change capabilities.
I don't think there is much to it, just alternate the side of the pattern table you use and as soon as a frame is ready start working on the next. Since you don't even need to modify the nametables, after the patterns have been draw all you have to do is update the palette (if the frame requested this) and use the alternate pattern table for the background.
Maybe each frame should specify a delay indicating for how long it should be displayed. You'd decrement this value every NES frame and only switch the new video frame in when this expires. This will allow you to variate the frame rate of the video and make use of
some temporal redundancy.
Quote:
Other good news is that polygon filling goes by much faster than line drawing, which is ironic.
Is it good news? If you have to do both, I guess it doesn't matter which is faster...
Quote:
The hard part will then be making the frames. I definitely need some sort of application/conversion program for this.
Yeah, coding more than a couple of frames by hand would be crazy!
Hey, how would you handle the animations with polygons ?
I've tried to use programs like Blender to have fun, but I could figure nothing out from it. I'd like to make one 3D model or two of characters to have some fun. It would definitely be funier to come with a creation that you can rotate in all sense than just a plain bitmap, for characters at least.
Also, it's very good you want not to use any illegal opcodes at any costs. I don't like them anyay and this preserves portability with other 6502 verions, increasing the chances of your techniques to work on a future day where all orginial NESes will be dead and only clones will be available on the market.
Yeah, all I need to do is define shapes with lines on each bit plane. There are some things I need to be concerned about that are rather annoying. For example, there needs to be an even number of pixels in the polygon outline in each column, otherwise the XOR fill will produce errors. This is only an issue when I have two lines intersecting at a point which is by itself in a column of pixels.
So I'll probably need to draw each frame and fine tune it so there aren't any errors, which will be tedious. I was planning a format similar to what you were saying. The format will probably be something like this:
$00-$FD - usable coordinates
$FE - New line
$FF - End of plane
This will be used for drawing the actual frame. Each "End of plane" should be good enough for defining where a frame ends.
The other part will just be frame address listings... I'm pretty sure I'll list them High/Low instead of Low/High, so I can use $0-$80 for commands. Probably $0-$3F will just mean the amount of time I want to show the frame for, like if I type $20,HighAdd,LowAdd, that means I want to show the frame at HighAdd/LowAdd for $20 frames.I could probably increase this number, as I don't think I need $40 extra bytes for commands.
About the filling taking less time, I was just saying it's good because the line drawing takes long enough as it is, and if the filling were to take longer this would only make things worse.
As for the display area, I'll have to just do some fine tuning for images that exceed the 256 tile limit. I plan for it to use most of the screen, though I might try some timed code to do palette changes during Hblank to make black widescreen bars on the top and bottom of the screen (Where the screen might be blanked anyways), and a different color #0 in the display area.
I have Maya on my computer for making 3D models. Though I barely understand anything from it, I plan to use it for most 3D planning like character creation and what I'm doing now. Though I might just make a 256x240 cartoon with MS paint and then convert it to my NES CG format somehow. I'm still not sure.
Celius wrote:
$FE - New line
$FF - End of plane
I don't think you need to specify when a line starts. Since lines is all that you use, and each of them has always 2 points, it's wasteful to keep indicating when a line starts. If you do it the polygon way, you just have to specify the coordinates of each point, with with only one byte of overhead, the one that finishes the polygon. If you have an overhead byte for each line, you'll be wasting a lot of space.
Quote:
About the filling taking less time, I was just saying it's good because the line drawing takes long enough as it is, and if the filling were to take longer this would only make things worse.
Makes sense! =)
Quote:
As for the display area, I'll have to just do some fine tuning for images that exceed the 256 tile limit.
Oh, so instead of having a fixed smaller area for the video you'll try to make use of spacial redundancy in real time? Sounds tough!
Quote:
I have Maya on my computer for making 3D models. Though I barely understand anything from it, I plan to use it for most 3D planning like character creation and what I'm doing now.
I don't think real 3D is the future of this, just polygonal animation sequences. Although I guess it would be OK to draw stuff over 3D images, just to give the illusion of 3D.
Quote:
Though I might just make a 256x240 cartoon with MS paint and then convert it to my NES CG format somehow.
Paint wouldn't be the best choice, because detecting lines and polygons in bitmap images is a very complicated and imprecise process. If I were you, I'd look into the
SVG format. They are basically XML files with tags for the shapes. With a good program that exports SVG files (Inkscape is free and pretty good!), it'd be a matter of converting a few tags you select to support into your format. Much easier than converting from raster images.
About the starting new lines, my format would basically "connect the dots" where it takes point A and B, and draws a line between them. But after that, point B becomes point A and a new set of coords is defined for point B. So I don't have to take 4 bytes for every line, I just need 2. Like I said, it's like those "connect the dots" puzzles where you basically draw from wherever you are to the next dot. The "new line" thing basically picks up the pencil and moves to the next defined point without drawing a new line. Sorry, I'm not very good at explaining things...
Also, polygon filling takes up as much CHR space as wireframe does + 3 tiles, so I don't think I'd be eating up CHR space by having a more full screen. I'm going to have to go through every frame by hand and adjust it so it doesn't use over 256 tiles, so it's just going to be tedious work. This sounds like it'd be really hard, but sometimes just shifting something 1 pixel to the left saves you a bunch of tiles.
I'm actually not sure what I'm going to do... I don't really know anything about other graphics formats. If I did a bitmap, I would probably use bright pink (Or some wierd color) points to define the points that I draw lines to, but I'll have to think some more.
Celius wrote:
The "new line" thing basically picks up the pencil and moves to the next defined point without drawing a new line.
Then "new line" is practly the same as "end polygon"... You know, many drawing APIs have a MoveTo command, which places the "pen" at a certain coordinate without drawing anything, and a LineTo command that draws a line from the current point to the next. Maybe something similar works for you? Well, enough of that, I'm sure you'll pick the format that works best for you.
Quote:
I'm going to have to go through every frame by hand and adjust it so it doesn't use over 256 tiles, so it's just going to be tedious work.
I don't know if you remember, but a while ago I wasn't sure about how I'd code my level editor, and in the end I made a program that converts BMPs (containing the drawings of the screens) into level map data. Because of my level compression, there is a limited number of blocks I can use, so the converter always indicates if I'm running out of blocks. Your conversion tool could do the same thing and indicate problematic frames.
Quote:
I'm actually not sure what I'm going to do... I don't really know anything about other graphics formats. If I did a bitmap, I would probably use bright pink (Or some wierd color) points to define the points that I draw lines to, but I'll have to think some more.
You could probably have points of the same color be part of the same polygon. This would make it easier for a converter to pick up the points. The hard part would be to guess the correct order of the points.
Did you check out the SVG format I told you about? I know it's another format and you are not familiar with it, but since SVG images are XML files, it means they can be read as text! Seriously, open them in notepad and you can read the whole image. Reading those files is piece of cake, you'd just have to look for the shapes you'll support (for example, there is a "<rect>" tag for rectangles) and convert them to your polygon type. You don't have to support it all, just the basic polygons, so you can ignore the rest. Much easier than making a vector (which your movie format is) out of a bitmap.
Yeah, I suppose end polygon and new line mean the same thing... Sorry about the confusion.
I've dealt with SVGs before, but I never really looked into the actual format of it before. I'll look more into this. I'll probably figure out more about my editor's capabilities after I look more at SVG format.
I'm afraid though about what I should do for drawing new frames... Since I can't use MMC3's scanline counter, I'm not sure what I'll do about blanking. Also, updating 1k of PPU data with only lda/sta absolute statements will take 8092 cycles. Obviously, I want this to be space efficient, so this isn't realistic. I figure if I used my current loop I figure it'll take about 9600 cycles, which isn't so bad for a loop considering how close it is to direct lda/sta.
And even worse, I need to update 5k of PPU data, so even if I could update a whole kilobyte a frame, it would take 5 frames just for updating, which doesn't include line drawing/polygon filling. I figure it'd take 1-2 frames to draw the virtual screen, so I'm looking at 60/7 = ~8.57 FPS. This is not a great frame rate.
Sorry for speaking in real time, but I just recalculated my loop length and it turns out for the name table update it'll only take 8600-8700 cycles! That's still like 76 scanlines, but if I blank around 40 scanlines on top and bottom (Though I've heard it screws things up when blanking on top), that'll get me enough time... Any ideas on how I should go about blanking? I suppose I could do a sprite 0 hit for the bottom part, and have fixed time code so it will keep the screen off and wrap around to the top and then shut it off after 40 scanlines or so have passed. Is this a bad idea?
I just trough something.
You should detect blank tiles and make them point to the same actual tiles. So if your image contains enough "blanks" areas, you could get a larger surface and still deal with the 256-tile limit.
The problem is that you then have to write to name table as well, as if pattern tables aren't enough.
Also, in a FMV, video, chances are that a frame will be very similar to the frame just before that. Using this cleverly would save you a lot of trouble I guess.
Bregalad wrote:
You should detect blank tiles and make them point to the same actual tiles. So if your image contains enough "blanks" areas, you could get a larger surface and still deal with the 256-tile limit.
The problem is that you then have to write to name table as well, as if pattern tables aren't enough.
I believe he's already doing that. He even said he has to update 5KB of data, probably 4KB of patterns and 1KB of nametable (although the whole image probably uses the same palette AND there's the widescreen border, so it should be less than 1024 bytes).
Quote:
Also, in a FMV, video, chances are that a frame will be very similar to the frame just before that. Using this cleverly would save you a lot of trouble I guess.
Yeah, we were discussing ways of taking advantage of temporal redundancy. But I think Celius wants to get the basics working, and then think of possible optimizations.
Yeah, my PSet function takes care of that. Given an X,Y pair, it fetches the tile at that set of coords from a copy of the name table in SRAM. If the tile ID is 0-3, then the tile is blank, and the next available tile in the pattern tables is put down. Though I still haven't implemented a key function: When it goes to the next tile, the next tile is going to be filled with color 0. If I check and the tile ID is #2 (Which means it's filled with color #2), and I'm filling on the opposite bit plane, it's going to set a blank color #0 tile there, and fill in what it needs to, leaving the part that would be color #2 color #0. I still get these errors, which is bad.
Another problem is that this uses as many tiles as wireframe does. Say you had a line that was going straight down on the very left edge of a tile. If you filled this in, it would be a solid color tile. Though my engine sees this as a unique tile, because it was made a unique tile in the line drawing engine. I think it would take too much of my valuable time to save tile space, so I just have to deal with it.
I was thinking of doing possibly layered video. For example, if there's a key item in the background that will always be there, why redefine it? Though I'll be getting the "glass" effect if I'm not careful; since my engine is layering bit planes of polygons, if I but a color #2 polygon over a color #1 polygon, it will turn to a color #3 polygon. Though this is desirable in many cases, it isn't most of the time.
I suppose I could do some sort of ANDing with the layers to eliminate this effect, but that might take too much time, which I barely have any of as it is.
Okay, I know this thread is kind of dead, and I don't have much to show, but! See for yourself a demo of polygons without illegal opcodes!
http://www.freewebs.com/the_bott/Polygon.nes
Okay, it's really not that exciting. There's not much to this demo I know, and I still haven't come up with a movie/format for a movie. It's basically a frame changing demo. But the glass effect is oddly fun to look at. I put this off for a while after I had to do away with the Bresenham line algorithm, because it wasn't fast enough. Now I can draw about 3 pixels per scanline for each line. This is good as a new pixel is only drawn for every X. So if a line is 128 pixels tall, and 2 pixels wide, I only draw 2 pixels. XOR filling will take a little longer though.
So now lines are defined with a 16-bit Y slope and an 8-bit X Run. So I have to rethink the format of movies a little more.
I still have to do a little optimizing, as it's running at less than 10 FPS. The best speed it could possibly run at is 12 FPS. It takes 5 frames to update the PPU. If I could draw the virtual screen in 160 scanlines, it would. But this isn't realistic, so it'll take a little more than a frame, making the frame rate 10 FPS. Oh well, it'll still be entertaining to watch!
If anyone wants to test this on a real NES, it needs 8k SRAM and 16k PRG. That's all. I'd be happy to hear if it works.
Oh, and usually I don't double post, but this time, I really don't care.
Well you did a very good job. I guess it's good not to rely on illegal opcodes.
It shouldn't be too impressive to the average user but at least the core of the thing is here. You'll probably do more impressive things later.
There is a few glitches in the leftmost 8 pixels tough. Maybe you should hide them using clipping ?
Oh, good point. I should have mentioned it. I'm actually not planning on showing anything in the leftmost column. The reason there are what seem to be glitches is because as I use a solid 8x8 pixel white tile to do a sprite #0 hit. I turn on clipping while I'm updating the "virtual" frame. This process will probably take longer, and if I don't turn on clipping, you'll see an ugly white tile on the side. I have to display this while updating the PPU though, as I read that sprite #0 hits only happen when the column is rendered. So it flashes in that column because clipping is turned on and off.
Here's how it would look without it:
http://www.freewebs.com/the_bott/polygon2.nes
Though it might look a little better on the side, that flashing white tile is distracting, don't you think?
Why don't you make the sprite zero the same color as background ? I could then be above the background of any color and hide it.
Man, that's really cool how it looks when it passes over that! Is that the glass effect you were talking about?
I have no clue about polygonal stuff and how it will be used for movies, but I do think it seems like a novel idea! I can't wait to see how you put this to work : )
It doesn't work in Nestopia?
Yes the glass effect is awesome. I don't know how you'll get any graphics with 2 polygons tough. How many polygons are needed to draw a character that looks close enough of an human ?
I'll try to find a tutorial to use blender to see stuff like that.
Nestopia disables SRAM automatically when it sees mapper 0 that's probably why it don't work (just like my "mode7" demo).
No, for some reason it doesn't work in Nestopia. I currently have it set to MMC3, and SRAM is enabled. The program is running, and it updates the palette correctly... Maybe for some reason it still isn't using SRAM. Why would it do that? Even if I don't do any of this during blanked portions of each frame, it still loads those stripes into the pattern tables. I wish Nestopia would have a few more basic debugging features, like pattern table VIEWING.
Oh, and I do clear SRAM before I write to it. I don't see what the problem would be. I'm not doing any fancy tricks or NES hardware specific features. After all, that's what I was trying to avoid. A sprite #0 hit for blanking, and I just turn on the screen again once it's done. This really shouldn't have anything to do with incorrectly resetting the scroll either, which I'm pretty sure I do as it works in FCEUXD and Nintendulator. So I think it'd be a problem with either writing to/reading from SRAM, or updating the pattern tables. It's not a problem with my algorithm, I don't think. Why wouldn't simple math work in Nestopia?
But the glass effect is what you were talking about Roth.
And about making movies, it would take a lot of polygons for every frame. Probably not 2! But this wouldn't cause much slow down or anything. Once virtual drawing passes the first 160 scanline mark (XOR filling takes most of this, too), it has a whole frame including Vblank more to keep updating. For the most complex of frames, it would have another. It waits until it's completely done.
Oh, and Bregalad; that's a GREAT idea! I'll go see about implementing that now.
EDIT: Okay, so here's something weird. I changed the mapper to MMC1, since I didn't do anything mapper specific besides access SRAM, I thought this would be okay. When I open up the file in Nintendulator, all of these updates are completely visible. But when I open it in Nestopia, it works perfectly fine. What is the deal with that?
I think I might be doing something wrong MMC3 related, because it doesn't work when I use MMC3 in Nestopia.
EDIT 2: Thanks so much for the suggestion Bregalad! Here's the new and improved demo:
http://www.freewebs.com/the_bott/polygonnoclip.nes
It looks a lot better without the flashing white line and clipping. The only thing I kind of regret is not being able to have visible borders to make it look more cinematic. But this would require a lot of work, as now I can take however long I want to draw the virtual frame. This means there is no blanking or timed code at all when that's drawn. The timing begins AFTER that. So if I were to have borders visible, they would be flashing and look bad.
EDIT 3: Maybe the final edit, but I just tested it on Nestopia, and it appears that the battery backup isn't being altered at all. I can change the data in it with a hex editor, and it will be untouched by the program. This is most likely the problem. Though it says that it's acknowledging the presence of SRAM...
So you changed the format in which the lines are stored to make everything faster. That's a wise decision, since it will be easy for the movie editor/converter to provide the values the engine needs. Can't wait to see an animation similar to the ones in Another World!
I'm glad you're excited. I am too! I still need to make a movie format; I just have it "manually" drawing these shapes. It basically always draw the dark shape where it is, and it draws the moving piece at a specific location + a decrementing variable for the X coord. This is just a demo of the frame changing concept working. Once I get a decent format, I can start making my movies!
Though size worries me a little. A one-minute movie might take up a great deal of space. But like we were saying, it is possible to make use of objects to reduce the amount of space eaten up.
I might also work with attributes to get a little color capability. Though it would be very limited, it could work. And also, it wouldn't take up that much space. I like this idea.
In the future, I might even add support for polygonal sprites! This would require a fair bit of work though. But it would be great for things passing over the BG that aren't the same color if I use attributes. Though this could be a really big amount of work, it could be an amazing result.
To make it work in NEStopia you have to write to a particular MMC3 register that enables SRAM. If you do nothing, by default NEStopia assumes it disabled (while other emulators assumes it enabled), and it doesn't work (I got this problem when hacking Gradius 2).
I don't know how many polygons an human creature would take but I bet at least 20 or something like that. If it takes you 9 frames to make 2 polygons, it would take 90 frames (1.5 sec) to draw a human model, which is way too long. I guess 0.5 sec would be a great maximum if you want to do any movie (it wouldn't look exeptional but still very impressive because it's the NES !).
If you want to do movies you'd better have to store directly coordinates else you'll have to do 3D matrix transformations which certainly would slow things down a lot. You could also store only coordinates that changes or something like that.
? 90 frames? No way! Maybe if I were drawing a line every frame!
The longest it would ever take to completely update a game frame is about 9 hardware frames. It's 5 frames ALWAYS to update the PPU data. Then it's 1-3 (usually 1) frames to draw the polygons in SRAM. 3 would be really complex frames. So actually, 3+5 = 8. 60/8 = 7.5 FPS. If I were drawing REALLY REALLY complex frames, the worst FPS would be like 6 FPS.
And my movies are stored 2 dimensionally. It'll be 5 bytes for a completely new line, and 3 if I am starting where I ended drawing the last line.
Thanks for telling me about the register! I completely didn't think about that. I'll go fix it now.
EDIT: Okay, so this one will work in NEStopia:
http://www.freewebs.com/the_bott/polygon.nes
Though I couldn't get it to run in 1.09, I got it working in 1.40, which I'm pretty sure is adequate. Also, NESTen runs it now, as it didn't before.
I tested it in several emulators, and it runs perfectly in NEStopia, FCEUXD, Nintendulator, Nessie, VirtuaNES, and I'm sure others that I didn't test. But I tested it in NESTen, NNNesterJ, and JNES, and the screen jumps around. Would this be a result of inaccurate emulating of setting the Y scroll midframe?
Oh, but surprise surprise, NESticle doesn't emulate this very well XD!
If it works perfectly in NEStopia, FCEUXD, and Nintendulator, is that a sign that the timing is adequate?
Oh I sure hope you'll be able to draw way more polygons with not having to take way more time. That would be really great.
About the scrolling I guess you should just write $0000 to $2006 right before enabling the screen and you should be okay (since you don't scroll). Possibly write $0400 to get the second nametable if you don't do a $2000 write afterward.
So I haven't created an application to make my frames, but I made one by hand today. I definitely need an application, because I've been working on this so long that I'm starting to get dizzy! But here's a legit frame:
The ROM that produced this image:
http://www.freewebs.com/the_bott/Polygon.nes
It will look a lot better once I have a program that will make it easier. But I think it's pretty cool for being all polygons with 1 palette!
I plan to have a shot like this, but when I add support for sprites (Both polygonal and predefined (I'll also add support for predefined BG tiles)), I plan to have the moon behind the building with clouds moving by that will appear behind the BG. These, I will probably have predefined, as the moon wouldn't look good made like an octagon. Though perhaps I'd have polygonal clouds to have that "glass" effect when they pass over the moon.
I worry though that it may look too much like cut out construction paper like the cartoon South Park. But I think this won't be as much of an issue once I have it actually moving "3-dimensionally".
EDIT: Oh, and this frame between 2 planes is 255 bytes (coincidence). It's 146 for color plane 1, and 99 for color plane 2. If this were all predefined, it would be much larger! There are some parts where I needlessly define "Start of new polygon" and stuff like that, so it's probably more like 245 bytes. It should also be noted that each plane separately has a maximum size of 255 (or 256, I don't know, I have trouble with the whole counting starts at 0 thing sometimes) bytes, so frames can be fairly complex. Though there's always 3 bytes used in the first plane, and 1 in the second. 1 in each is to define the number of lines being drawn.
I must admit it is pretty cool to know that this scene was drawn dynamically! However, I am concerned about tile usage... when I look at the tiles that were generated for this picture, I can see that 3/4 of the pattern table were used, even though the image looks pretty simple, with lots of flat areas. It might be hard to keep them inside the limits once there are characters moving around and all that.
BTW, how do you know when to reuse tiles and when to create new ones? I'm really curious about that! Are only the first 4 reused or is there a more complex system?
This is one of the problems with the engine... I really don't think I have enough CPU time to sacrifice to check and see if I can reuse tiles for things like completely horizontal/vertical lines. Though there is somewhat of a solution, and I use it for things like the tree trunks.
Only the first four tiles are reused, yes. If I have large polygons that are filled with one solid color, it would be a really bad idea to use all "unique" tiles to do it. So I use those 4 tiles for solid areas in the middle of a large polygon. And also, I define absolutely no completely vertical lines. In order to define a square, I have to define the top and bottom borders of it. If I make it start at an X coordinate that's a multiple of 8, and if I make it a multiple of 8 pixels wide, I can fill it with those solid tiles all the way down besides the top/bottom lines. This saves tiles, and I do it with the tree trunks. Check all the tiles in FCEUXD; They are almost completely made up of one of the first 4 tiles.
But in a lot of cases, I can fine tune the graphics to use less tiles. If I have a line with a slope of 1, there is one condition where it can use half as many tiles as it ever does. If the line cuts exactly across the tile from the top left corner to the bottom right, then it will use much less tiles. If it's slightly off, it will use twice as many! There are many tricks like this to reduce the amount of space used.
I'll most likely program my application to warn me if all tiles are used up, or anything like that. But most of the frames will have side-by-side polygons sharing many tiles. So this isn't SO much of an issue right now. I don't plan to have REALLY complex frames, as this isn't so possible with only 256 tiles.
Oh, and it also helps that there are lots of long horizontal lines in this, and I currently have to define every one with unique tiles. However, I have an idea for a solution of this. I'll have a special command in my line definitions that tells to draw a row or column of solid tiles instead of using unique tiles. Though this would take an extra byte as a line definition, it would save me lots of pattern table space.
Well it's pretty good you were able to put this much polygons.
You should learn how to use blender. I gess there is a lot of tutorials in english. I also found a tutorial in french I'm going to use to learn at least the basics. When I get the basics done if I want to move further I could switch to more complex english tutorials, but I don't want to deal with that now.
I guess you shouldn't draw clouds and moon at the same time. If you have ever looked the sky during the night, you'll probably notice that clouds are invisible you only notice the "absence of stars" in that direction (of course not technially the absence of stars but you don't see them).
Oh and it's possible to have the sky during daytime with clouds and the moon, but it would look stupid without the sun then, altough it would be possible to have the moon on the north and the sun invisible on the south, and cloud arround it, so that would be possible.
Bregalad wrote:
Well it's pretty good you were able to put this much polygons.
You should learn how to use blender. I gess there is a lot of tutorials in english. I also found a tutorial in french I'm going to use to learn at least the basics. When I get the basics done if I want to move further I could switch to more complex english tutorials, but I don't want to deal with that now.
I guess you shouldn't draw clouds and moon at the same time. If you have ever looked the sky during the night, you'll probably notice that clouds are invisible you only notice the "absence of stars" in that direction (of course not technially the absence of stars but you don't see them).
Oh and it's possible to have the sky during daytime with clouds and the moon, but it would look stupid without the sun then, altough it would be possible to have the moon on the north and the sun invisible on the south, and cloud arround it, so that would be possible.
is that even relevant?
what in god's holy name does the rediculously high poly-count, raycasting, pre-rendered image program "Blender" have to do with the NES?
Well, you could use that software to render a low poly-count model that you could trace over/convert to make it usable in my current polygon-drawing engine for the NES. That's what it has to do with it. Did you read the thread?
Oh, and also, there are very few actual polygons in this picture. The engine doesn't care as much about the number of polygons as it does the number of lines. In fact, any polygons that are the same color that appear to be overlapping are not 2 separate polygons, but 1 big polygon.
EDIT: Okay, so I've done a little modification to save tiles by adding support for drawing rows of solid tiles. Also, I can't believe I missed this, but I wasn't correctly starting a new column when I was filling, so it was as if I were filling one big column for the whole thing! So I fixed this, and now I can "cheat" by not defining the bottom border of a polygon if it's off screen. This uses less tiles and line defs! So have a look just at what impact the little modifications I did had:
http://www.freewebs.com/the_bott/Polygon.nes
That uses much less tiles! Though I don't want to right now, this image could be heavily modified to use WAY less tiles now that I have my routine. For instance, the top part of the building could be a row of solid tiles instead of unique ones. Though they act just like lines do. I can't just leave a row by itself. I would like to take the chimney top and use solid tiles instead of unique ones, but it would start filling all the way down the screen, which would be bad.
But it can't be TOO modified, otherwise the movies will look really strange if everything "snaps" to tile boundries and whatnot.
Celius wrote:
Well, you could use that software to render a low poly-count model that you could trace over/convert to make it usable in my current polygon-drawing engine for the NES. That's what it has to do with it. Did you read the thread?
Oh, and also, there are very few actual polygons in this picture. The engine doesn't care as much about the number of polygons as it does the number of lines. In fact, any polygons that are the same color that appear to be overlapping are not 2 separate polygons, but 1 big polygon.
EDIT: Okay, so I've done a little modification to save tiles by adding support for drawing rows of solid tiles. Also, I can't believe I missed this, but I wasn't correctly starting a new column when I was filling, so it was as if I were filling one big column for the whole thing! So I fixed this, and now I can "cheat" by not defining the bottom border of a polygon if it's off screen. This uses less tiles and line defs! So have a look just at what impact the little modifications I did had:
http://www.freewebs.com/the_bott/Polygon.nesThat uses much less tiles! Though I don't want to right now, this image could be heavily modified to use WAY less tiles now that I have my routine. For instance, the top part of the building could be a row of solid tiles instead of unique ones. Though they act just like lines do. I can't just leave a row by itself. I would like to take the chimney top and use solid tiles instead of unique ones, but it would start filling all the way down the screen, which would be bad.
But it can't be TOO modified, otherwise the movies will look really strange if everything "snaps" to tile boundries and whatnot.
make a demo of a dotted line wireframe seashell, a multi-colored spinning icosahedron, along with a third animated scene of a set of eight octahedrons orbiting a center point passing in front of each other.
This is some of what i did in the first VGA graphics demo i did for PC using QBasic called '19990328.EXE'.
in order to render a convex polyhedron all you need to do is test whether the vertices are clockwise or counter-clockwise per triangle and only render ones that are clockwise on the screen.
then for multiple convex polyhedrons you need to split triangles into 2 or 3 new triangles every time two triangles intersect in 3d space, and use an algorithm to only draw triangles that aren't completely engulfed by other polyhedrons.
you need to also for concave polyhedrons, figure out how to split them into multiple convex polyhedrons.
also you need to figure out how to skip rendering any triangles that are completely masked by other triangles.
also you need to figure out how to shave off pieces of triangles that do not need to be rendered.
beyond that it is simple gourad dithering and texturing.
forget lighting effects on the nes, btw.
you need "QBasic" 1.1 for this, use GliDOS, DOSBOX won't work with the palette rotation.
"Quick Basic" 4.5 might work, but "QBX" PDS 7.1/7.2 isn't compatible with the source code.
http://mediaplague.com/projects/jargon/19990328/MS-QBX/source/19990328%20%28QBX%29%20%28full%20src%29.LZMA.7z
Code:
19990328.BAS
3DFLOOR8.BAS
are the two major source codes to look at.
3DFLOOR8.BAS does a majora's mask style effect that i just happened to independently create unaware of each other's project the same time nintendo did it.
why no emu uses this effect by interpolating 3 to 7 frames of the same pixels on top of each other using a weighted average instead of using frame-skip, i have no idea.
with this method you don't have to render the entire screen per frame.
reminds me of windows 3.11 'mouse trails', only a lot cooler looking.
jargon, you could have waited for Celius to say if he was interested in your suggestions before explaining all of this. My guess is he isn't, because his goal for this engine is not to make one of those "super cool mega demos", he's actually trying to be original and make movies of things that actually resemble things you'd find in a real (or fantasy) world, like the entities in an actual a game.
When you start talking like that it just seems you are showing off, trying to make us see the cool stuff you have made. But instead, you end up looking like a dick who thinks he knows more than everyone else.
It's like you vomit all that jargon (BTW, is that where your name comes from?) on purpose to throw people off... it just doesn't help anyone.
I will admit, those demos are extremely cool! The best thing I've made on QBasic was my wireframe 3D simulator. It was like yours, but it didn't have mouse support or different colors. But you could spin the models around and move them all about. Oh, and there was no polygon filling as I didn't know how to do any at the time.
But my polygon engine wouldn't be able to do those simply because it assumes everything is pre-defined. And overlapping polygons of the same color cause major issues with the filling routine. I originally planned on having 3D sequences, but then over the course of about 6 months I concluded several things about this weren't necessary for making a polygonal sequences.
Making a demo like that on the NES would be cool, but like tokumaru said, I'm not into making random demos that I'm not going to use for anything besides just being a demo.
Celius wrote:
But my polygon engine wouldn't be able to do those simply because it assumes everything is pre-defined.
Celius, I assume your rendering engine reads the data using a pointer, right? Theoretically, you could generate a dynamic scene to RAM and have your engine render that data. The only problems I see are the extra time needed to create the scene (too much time is already spent rendering it), and the lack of complexity checks (to make sure no more than 256 tiles are used).
Yes, my engine uses a pointer to get the data. Several, actually. But it is theoretically possible to do real 3D rendering with my engine, though it'd be terribly slow and the complex checks would take way too long. It'd run at like a frame a second, probably XD.
Also, the display area is 160 scanlines large. There are 40 on top and bottom that aren't visible. This isn't a very good looking display area for a game. It would be a headache to play, probably. It's fine for movies, since it makes it more cinematic like widescreen.
Celius wrote:
Also, the display area is 160 scanlines large. There are 40 on top and bottom that aren't visible. This isn't a very good looking display area for a game.
If you don't have a status bar, that should be enough for a game. Some systems have only 192 scanlines, after using some for a status bar only about 160 are left for the game, and many games like that exist.
Anyway, I wasn't talking about a game, just a dynamic demo, where the frames wouldn't need to be pre-stored in the ROM. Although I think Another World uses the polygon engine through the whole game, and it worked out pretty well.
I understand why it wouldn't work in your case... The CPU is already pretty busy as it is, if it had to process game logic as well, it'd run at 1 FPS, like you said.
tokumaru wrote:
jargon, you could have waited for Celius to say if he was interested in your suggestions before explaining all of this. My guess is he isn't, because his goal for this engine is not to make one of those "super cool mega demos", he's actually trying to be original and make movies of things that actually resemble things you'd find in a real (or fantasy) world, like the entities in an actual a game.
When you start talking like that it just seems you are showing off, trying to make us see the cool stuff you have made. But instead, you end up looking like a dick who thinks he knows more than everyone else.
It's like you vomit all that jargon (BTW, is that where your name comes from?) on purpose to throw people off... it just doesn't help anyone.
you apparently don't realize that in the 90s there was no nesdev retro-gaming scene. at the time the major retro-gaming scene was for QBasic.
the coming of both rpgmaker and emulation were the death of QBasic retro-gaming.
Celius wrote:
Yes, my engine uses a pointer to get the data. Several, actually. But it is theoretically possible to do real 3D rendering with my engine, though it'd be terribly slow and the complex checks would take way too long. It'd run at like a frame a second, probably XD.
Also, the display area is 160 scanlines large. There are 40 on top and bottom that aren't visible. This isn't a very good looking display area for a game. It would be a headache to play, probably. It's fine for movies, since it makes it more cinematic like widescreen.
originally 3dfloor8 only ran at one frame a second, and it looked great due to the blitting effect i used in order to span between frames.
jargon wrote:
you apparently don't realize that in the 90s there was no nesdev retro-gaming scene. at the time the major retro-gaming scene was for QBasic.
Wrong.
jargon wrote:
at the time the major retro-gaming scene was for QBasic.
Although the QBasic scene was quite active (I followed it pretty closely from 1996 to about 2001), i don't think it was the "major" one. I don't know if emulation killed it, but I certainly left QB for the NES.