I've made a programm who can perform scaling and rotating on the NES on a small 64x64 pixel zone unsing CHRRAM and matrix multiply and on both bitplanes. The source and ROM image are uploaded
here (it assembles with WLA-DX).
Scale the picture with up and down, and rotate it with left and right. A reset scaling and B reset rotating.
However, due to the slow CPU of the NES, it currently takes about 90 frames for the CPU to process the image (the CPU should perform 4096 times the process of matrix multiply, ROM acess/bit shifts to read the poper pixel, and then write it on the ouput buffer).
I recommend using an emulator with very high frameskipping features (like VirtuaNES) for now.
If anyone have idea how fast this up (exept making the mode 7 zone smaller), by all means say it !
For one thing, you don't need to matrix multiply at all. You can add the texels per horizontal pixel after drawing each pixel, and then you can add the texels per vertical pixel after drawing each line.
Yeah, what you said should probably work better for scaling only, but when if comes to scaling+rotating, I don't know if this method is any better effective than matrix multiply. The approach is different, instead of having a fixed output pixel position and calculate it's corresponding input pixel, you do the other way arround, take a fixed input pixel and calculate where on the output it should be. This will need much less time when it comes to reading original pixels, but you'll need a huge routine calculating where those should be put on the output buffer anyway. Also you'll need to buffer the whole frame at once doing it like this.
I just wanted to do the matrix approach to do it like the SNES does, but if I were to implement some kind of scaling in a game I wouldn't do it as it because it's way too slow.
Bregalad wrote:
I just wanted to do the matrix approach to do it like the SNES does
The Super NES and Game Boy Advance actually use the incremental approach that I outlined, where your "input pixel" is called a "texel".
Quote:
but if I were to implement some kind of scaling in a game I wouldn't do it as it because it's way too slow.
Once, I investigated scaling for 32x32 pixel sprite cels, but my back-of-envelope cycle counting showed that it would run way too slow for what I wanted to do with it. Precomputed rotation is probably the only rotation that can be done in real time on the NES, but I'd love for someone to prove me wrong.
I don't know too much about mode 7, as in, I don't know how the SNES does it. But I was thinking, is it possible to make a LINE function like that of Qbasic, and apply it to the NES? If so, I think if it was fast enough, it could be applied to making a rotating object.
Yes, EXACTLY like Elite. That is the game I was thinking about. But I don't know how that game does it's line function. Actually, I made a wireframe simulator in Qbasic using a combination of the line function and the raycasting equation. I was thinking I could transfer it to the NES someday like Elite. However, I'm just wondering about the line function itself and how it works. It seems incredibly difficult to deal with slopes and whatnot when you're working with 1 dimension. This concept could be applied to rotating a block of graphical data.
You'd need to set up CHR RAM to treat it as one big bitmap. Both Qix and Videomation do this.
What exactly do you mean by that?
Elite does not set up VRAM as a bitmap, it assigns tiles dynamically.
Dwedit wrote:
Elite does not set up VRAM as a bitmap, it assigns tiles dynamically.
- AFAIK, it's because Elite works with line segments.
Honnestly, I'd say wireframe doesn't look too good for a game. I'd look good on the screen of a computer inside of a game or something like this, but a game (or miniagame) made entierely of wireframe like Elite would become quickly annoying.
To draw a line, I guess the easiest way is to have your start point and ending point, and then start drawing the start point, increase X by some amount and Y by some other amount (the amount is some fraction of the vector made from the differences of the coordinate between your start point and end point), and continue like that unltil you reach the end point. The problem is that if you may loose presision and "miss" the end point.
Acess the CHRRAM on a pixel based fashion is incredibly confusing and slow (in fact my Mode7 ROM doesn't do this, it acess the CHR data in ROM in that fashion, but the way to acess it is exactly the same).
Bregalad wrote:
To draw a line, I guess the easiest way is to have your start point and ending point, and then start drawing the start point, increase X by some amount and Y by some other amount (the amount is some fraction of the vector made from the differences of the coordinate between your start point and end point), and continue like that unltil you reach the end point. The problem is that if you may loose presision and "miss" the end point.
Look up Bresenham's line algorithm. It's fast, doesn't use multiplications or divisions and uses only integers. This is as good as it gets with lines.
drawing circles, parabolas, hyperbolas, and ellipses are just about as computationally easy as lines.
Very cool! I've always loved bitmap rotators.
Perhaps it would be possible doing a fullscreen 4x4 bitmap rotator, each pixel representing 4x4 pixels of a tile. Would perhaps be a bit faster at the cost of resolution?
Yes, that would use exactly 256 tiles for possibilty. However, the resolution would be 32/2x30/2 wich is 16x15. It should then be about 4 times faster than my current demo. Maybe worth a try, altrough I doubt it will look any good.
I'm looking forward to a new "demo" soon then.
I remember on the Amiga when using "low-resolution" graphics (like 4x4 or even 8x8 pixelblocks), sometimes every second pixelrow was scrolled a few pixels to the right to simulate "dithering". I'm not sure if this would work on the NES or perhaps it would take alot of raster-time to make it possible..
Hey, I've finally done a working version of a NES mode 7 screen that :
- Uses the whole screen with bigger 4x2 pixels
- Is a lot faster (uses enormous lockout table+self modifying code), but it's still slow (it takes 36 frames to update the image instead of about 100 as before).
- Is still made of 64x64 "pixels", but this time it takes slighly more than one scanline to calculate it, and it does both timed $2000 writes and maths at the same time, leaving a little time for the CPU to do something else on the bottom of the screen
- Only uses NROM-128 configuration, but with SRAM (SRAM is used only to decompress the image's graphics, it could be ROM as well, but waste a lot of space). Also, the battery bit is set so that Nintendulator and Nestopia emulates SRAM, but there is no battery needed technically.
You can dowload this demo here :
http://jonathan.microclub.ch/rotation
Note : It works as exepted in Nestopia, Nintendulator, VirtuaNES and FCEUltra (don't work only on Nesticle so far) but I really wish someone would test this on hardware, because I have no EPROM programmer, and even if I had I couldn't port the demo to PAL timing, because it uses all NTSC cycles for calculation exept 3 or 4, and PAL timing is shorter.
Wow, this looks pretty cool! It's a lot smoother than the other one. It seems that pre-defined large pixels can actually do a lot. I was considering using them for a ray-casting demo on the NES. But this is kind of a break-through. Mode 7 on the NES is really possible without looking bad.
...and it works with RockNES too. Why do you always make RockNES blind between us?
I'm glad you guys like it, I don't mention RockNES because I haven't installed it on my PC but I will if you insist.
Personally I think the big pixels doesn't good really good, especially when scaling the thing down. While technically havin the same number of "pixels" than the old one, this one looks better because it takes the whole screen but worse because of big pixels.
Just a suggestion:
For this demo, you should update the next frame on one name table, and have the camera on the other, and after the other name table is done updating, just switch over to it. So you don't see the updates.
I already use both nametables to make pixels smaller vertically (4x2 instead of 4x4), so this wouldn't be possible without 4-screen mirroring.
If you didn't even notice that I should belive my timed code is perfect then (it probably isn't).
Wow I really hate when a site is down
CKY-2K/Clay Man wrote:
Wow I really hate when a site is down
Are you suggesting Bregalad's site is down? I was able to get on it just fine.
CKY-2K/Clay Man wrote:
Wow I really hate when a site is down
If you ARE referring to Bregalad's site, I usually have the same problem. I have to use a proxy site to access it, so maybe that will help you too.
Roth wrote:
CKY-2K/Clay Man wrote:
Wow I really hate when a site is down
If you ARE referring to Bregalad's site, I usually have the same problem. I have to use a proxy site to access it, so maybe that will help you too.
Yes, but when I use vtunnel.com the NES rom directs me to a bunch of text shit.
Well, my "site" (http place where I upload my stuff would be more correct) doesn't seem down, but the link just points to a repertory (no index.html here), maybe this cause problem in some browsers (it doesn't in Firefox).
If you're just interested in the rom (and not in the source) then download from the following rom instead :
http://jonathan.microclub.ch/rotation/rotation.nes
It wont work in firefox either.
CKY-2K/Clay Man wrote:
Roth wrote:
CKY-2K/Clay Man wrote:
Wow I really hate when a site is down
If you ARE referring to Bregalad's site, I usually have the same problem. I have to use a proxy site to access it, so maybe that will help you too.
Yes, but when I use vtunnel.com the NES rom directs me to a bunch of text shit.
If that happens, you could try Save Page As -> rotation.nes. I'm not sure, but that _might_ corrupt it, because it might save it improperly. If so, do a Google search for "proxy". When I got on there, I wasn't able to right click save as on the file. When I clicked on it, it went directly to open/download it (Firefox). If you can't get it from that, then I don't know what else to tell you : P
In any case, the demo is really cool, Bregalad! Nice work!
nes with Powerpak: white screen with text on bottom. So no worky.
Hmm.... Did the powerpack emulate SRAM with mapper 0 games (I enabled the battery bit so that it works in nestopia, clearing it will disable SRAM and the demo requires SRAM) ?
Yes, the Powerpak has 32k of ram set aside for save ram. Whenever it sees any sort of write to the save ram, and when you press and hold reset for three seconds, it will prompt to save the ram to the Compact Flash. With this rom, it prompts so it would seem the Powerpak is seeing the sram contents being written.