This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - thepenguin77
Pages: 1 ... 92 93 [94] 95 96 ... 108
1396
« on: August 13, 2010, 01:06:31 pm »
Those sprites look so good, they look even better when they flow together. With these newest additions, all I can say is wow.
On another note, I'm going to have to start, clipping all these sprites. I left in all the white space just to make it easier, but now they take up 3,969 bytes in the program, and 9,261 bytes unpacked on calc. I've used up 14kb of the extra ram page. So that's next on my agenda.
Here's the latest if anyone wants to give it a go.
Edit:
Jk, I use 15kb of extra ram.
1397
« on: August 12, 2010, 11:14:06 pm »
That's so awesome. I like getting new sprites from you because they are so easy to add. Just convert/copy/paste. Whereas the ships sprites take a bit of work to get right. Oh well, they're both needed.
You'll definitely be on that credits page too.
1398
« on: August 12, 2010, 10:51:13 pm »
If you fill that whole template, this will be the coolest looking game ever.  Yes, I'll need all of those directions. I'll mirror over the other set on-calc. I really must thank you for all of these sprites, I'll have to make a credits page in the game and get your name in there. 200th post. Yay
1399
« on: August 12, 2010, 10:34:56 pm »
That would work. I forgot about edge lines. I used to use them, but then I realized with grayscale they weren't needed.
1400
« on: August 12, 2010, 09:43:57 pm »
@Magic banana
Those look great. Diagonals will probably be needed too. I'll add in the 2 degrees of turning also. With all these great directional sprites, I'm going to have to start working on angled shots. That will be interesting. Also, I suck at sprites, I forgot about braking/boosting, but I guess you'll have to resize those too.
@shmibs
Making the wireframe is the easy part. Filling them in is where it gets really hard. You basically need grayscale to do make it look right. But here's how I did it. First you make a buffer the size of your screen Y * 2 * corners. So mine is a static 48 * 2 * 4 = 384 bytes. Then you draw data lines connecting your corners if your shape. These data lines are defined by a farthest left and farthest right in each row. So if its a vertical line, its min and max are the same number. If its horizontal, its min is its start and max is its end. And for diagonals you do the same thing, just for each row you find min and max. Then once you have your lines drawn, you step through each row, find the lowest min and highest max, and shade the area in between. I can't imagine doing this fast in anything but asm though.
@tloz
I'll make sure to include that sketchy character that your talking about. I've heard his name somewhere...
1401
« on: August 12, 2010, 04:11:41 pm »
I think he means, instead of having greyscale, have it in black and white but with a texture that approximates the grey.
Well if that's it, I can't do it. That would probably be slower than grayscale. vPutMap disables interrupts because it can write to the screen. TI wasn't smart enough to only disable interrupts if in fact it actually does write to the screen.
1402
« on: August 12, 2010, 03:58:43 pm »
Um... Thanks Iambian. lol Thanks for the info. Sorry if I offend you by what I am going to say next but couldn't you better use dithering instead of grayscale and let it take up the whole screen? Altough a clear side effect would be that you can't have custom sized sprites...(well you can but it's slightly slower I guess). Don't get me wrong. I like greyscale, I was just wondering if it would be practical/faster.
I don't care if people offer suggestions. Someone might make the game twice as fast I'm not exactly sure what you mean by dithering, but if you mean mostly one color with speckles of the other. Then the way I draw the polygons would make that way slower. I can only draw solid colored shapes. Now for the update. I have included Magic Banana's and tloz's sprites to create the barrel roll. Since all 24 sprites for the barrel roll were going to be 4,536 bytes, I only included 6 and rotate the rest out when the program starts. I also had to write my own vPutS routine because the OS one disables interrupts for a second. But no worries, it searches the os for the letter sprites, it doesn't keep the entire set in the program.
1403
« on: August 12, 2010, 10:52:47 am »
I'm not exactly sure how many it can handle. Space wise, it could do in the thousands. But as far as speed, I would imagine at 7 or 8 tiles of 4 polygons each you would notice slow downs. But I haven't tried it yet.
No lighting. I will now talk about another shortcut related to that. I store all the vertices in a table xyz. Then I have a table right after it which defines all the polygons. They each say what vertices they use, what color they are, and what side they are viewable from. So for instance:
tDarkQuad(dLeft, 0, 3, 7, 4)
I'm not even going to step through it. But what's important is that the shape is only drawn if the screen's x coordinate is left of vertex 0.
1404
« on: August 12, 2010, 12:40:31 am »
This is astounding! The quality and speed of this is incredible! Are you using ZSorting? How are you dealing with the depth sorting problem?
Ehh... I'm not. I just try to layer it so that it looks nice. If I can figure out a fast way to do it, I will, but currently I draw: tile map, enemies, bullets, ship. For the most part, everything is usually in this order. The problem I see with massive sorting is that I would have to make some big buffer that keeps track of everything to be written the the screen polygon or sprite. And then sort through it. I could do it, I just don't know if it would kill my speed. Part of the reason this runs so fast is because I use shortcuts like this.
1405
« on: August 11, 2010, 10:53:25 pm »
I don't know how to rotate, but head on is pretty simple. The general gist is that you take the verteces, convert them to screen coordinates, and then draw in shapes to connect them.
Just to make a standard, if you are looking parallel to the ground, x increases to your right, y increases as you get lower, and z increases as you walk forward. When I say differences, I am talking about it's value, subtract your own. So its at 5 you're at 2. 5-2= 3 difference.
First, you have to figure out you base length. Which comes from half your screen length/tan(half field of view). So in my case, 48/2 / tan(60/2 = 42 base length. This is the only part that I got from tutorials.
Second, you take your base unit and divide it by the Z difference of the point you are mapping. This will tell you how many standard units it is away, and therefore how big it is. If it is one away, it is normal size. Two away, 1/2 size. 3 away, 1/3 size, and so on.
Then you take it's size ratio and multiply its x and y difference by the ratio. In this step, you might have negative differences, so just be aware of that.
Finally, add half the width or height of the screen to the x and y to get your screen coordinates.
The rest comes from drawing polygons that connect these points on screen.
Now an example.
Point is 120 away, 50 to the right, and 30 above. Screen is 48*48.
48/2 / tan(60/2 = 42 base unit.
42/120 = .35 actual size
50*.35 = 18 relative pixels right
-35*.35 = -11 relative units down
(18+(48/2), -11+(48/2))
(42, 13)
1406
« on: August 11, 2010, 10:08:51 pm »
Wow, are you guys just that good at spriting that you can draw that stuff? Those look amazing. As soon as I get my pic converter working again, (I had to add in a masking byte), I'll definitely have it doing barrel rolls.
1407
« on: August 11, 2010, 08:36:20 pm »
I basically will use the blackspace for HUD stuff. So the bottom middle will be incoming messages. Left and right will be health, and lives and such.
Sprite size? I really don't have any limits as long as it looks normal. The ship is like 19 pixels wide currently, so anything will do. When it does a barrel roll, it will be like 15*15 at one point, so I really don't care what size they are. The enemies can be whatever size also, they just preferably need to have a close pic and a far pic. The close one is about 12 wide and the far one is about 8. 4 level grayscale, but you have to use white carefully as it is the background color, for now at least.
Also, black and white characters would be cool, I know at least I'll need peppy. Some cool design to fill up the blackspace will eventually be needed too.
Yes, only 15MHz. If I did this in 6MHz I would be the z80 god.
1408
« on: August 11, 2010, 06:00:25 pm »
It's straight ASM. I don't program calcs with anything else. If Axe could get raycasting like that, Quigbo will be hailed as a legend! So, that'll be the next milestone! 
not to mention the greyscale with it. 
I was waiting for this. This isn't raycasting. The way you can tell is because the objects don't have to be vertical. I could make whatever tile I want. I could even make a dolphin if I felt like it. Something to help poeple ignore the small screen space is a really fancy HUD. it helps a lot to see purpose in the bars of white
That's exactly what I was thinking. If I make some awesome background picture, people won't notice at first that the game is 48*48. But in all honesty, 48*48 is a lot better resolution than I originally thought.
1409
« on: August 11, 2010, 05:48:20 pm »
I don't think I can go any bigger. Grayscale wise: 48*48 = 18% cpu 64*64 = 31% cpu 96*64 = 47% cpu Then drawing the triangle and quads takes most of the processing time, so if those had to do more, it might really slow down. It's already running at about 90%. And I still have to add more enemies and more objects. But, in the end, if I can, I'll bump it up to 64*64. 
WOAH! That's awesome! Can't wait to see how this turns out!
(don't forget about barrel rolls  )
I'd never forget the barrel roll. That's part of why I put the screen at the top instead of centered. This way there's room for "Do a barrel roll!"
1410
« on: August 11, 2010, 05:29:41 pm »
For all you googlers out there. Here's the newest screenshot:  And here's the post containing the newest version.
Stop reading. Watch the screenshot VV That's right, 4 level grayscale, polygon 3d Star Fox. I've only been working on it for about a week so it still has a long way to go, but it's still awsome. A few days ago, I searched polygon 3d graphics on google, once I got the general idea for how they are stored in memory, I made a wire frame program. I realized how easy it actually was because I had a 3d cube on my calculator in about two hours, so then I thought, star fox? To make this work, it had to be grayscale because without it, you couldn't see anything. To accommodate this, I changed the screen to 48 by 48. Then after a long while of creating an arbitrary triangle and a quadrilateral drawer. I had 3d graphics. Every thing in the game is super easy to change, I can add new objects, change the level, and make the enemies better. Right now, the enemies suck, but that's because they were the most recent addition. Here are some general specs on the game: 48x48 screen 60 hz 4 level grayscale The rest of the screen is updated at 7.5 hz. Gameplay is held at 15 fps for now. Each "tile" is 48x48 The tilemap is 9*12. (deeper than wide) If anyone hates my sprites, I'll gladly accept new ones. Even new enemies that I haven't created yet. Just watch star fox snes on youtube. I'm a programmer, not a spriter. I'll keep posting progress as it comes.
Pages: 1 ... 92 93 [94] 95 96 ... 108
|
Show Posts