ITS_Mike







Programmer





Level 3Programmer Re: Codename: Warplane - Classic Arcade-Style WW2 SHMUP « Reply #20 on: September 13, 2013, 03:46:51 PM »



@panicBarn: I don't want the game to deviate from the genre too much. One feature we are prototyping though is an ammo-limited cannon in addition to your normal weapon (which is not ammo-limited). I can't remember a classic SHMUP which had a weapon like this, so it could be considered unusual



Thanks for the replies everyone! @trentg: The game will be similar to 1942, especially since it will be over the ocean and there will be boss fights. We plan on having at least one enemy warship though, where 1942 only had enemy warplanes. There will be more bullets on screen than there were in 1942, but we definitely do not want as many as are commonly seen in "bullet hell" SHMUPs.@panicBarn: I don't want the game to deviate from the genre too much. One feature we are prototyping though is an ammo-limited cannon in addition to your normal weapon (which is not ammo-limited). I can't remember a classic SHMUP which had a weapon like this, so it could be considered unusualThanks for the replies everyone! Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer CRT Effect Mockup « Reply #21 on: September 13, 2013, 04:10:11 PM »



Original (no CRT effect)





CRT Effect (click to enlarge)





Now I need to get it working in-game The effect is currently a little big, since I am using a 2x2 square of pixels to represent one element of the CRT display. I'm probably going to reduce that to a 1-to-1 ratio. You won't be able to make out the phosphors at that size, but it should still look good. I think I've finally figured out the theory behind the CRT effect. Here is a mockup I did in Jasc Paint Shop Pro:Now I need to get it working in-gameThe effect is currently a little big, since I am using a 2x2 square of pixels to represent one element of the CRT display. I'm probably going to reduce that to a 1-to-1 ratio. You won't be able to make out the phosphors at that size, but it should still look good. Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer The Devil's Details: AGAL Edition Plus Scanline Shader « Reply #24 on: September 14, 2013, 08:47:31 PM »



The Devil's Details



1. No Immediate Values

This is a bit of a pain. You can't say simply "add ft0, 5, 10" in order to add 5 + 10 and put the result in ft0; instead, you have to place 5 and 10 into constant registers from your program before you render! This applies to any immediate value, so you also can't do something like "mov oc, [1, 0, 0, 1]" to output a red color, or "mul ft0, v0, 2" to double the value of a varying register. You would have to do something like "add ft0.x, fc0.x, fc0.y" or "mov oc, fc0" or "mul ft0, v0, fc0.x".



2. Lines Must End in a Line Feed!

If you are constructing the shader's source code within an ActionScript file by building a string please do not forget to end each line with "

"!

For example, do this:

Code: fragmentSource = "mov ft0, fc0

" + "mov oc, ft0

";

not this:

Code: fragmentSource = "mov ft0, fc0" + "mov oc, ft0";

Forgetting the line feeds will cause really strange errors that are in no way helpful! For example: "Fragment Write All Components".



3. Triangle Lists Only: No Triangle Strips, Fans, etc.

The only supported render type is a triangle list. You can use an index buffer to mitigate the effects of this, so I don't think it will be a show-stopper. It's something to be aware of though.



4. Cannot Render to Texture Subregion

If you are rendering to a texture, there is no way to tell it what subregion to render to; the entire texture will be used. This is a little bit of a problem for me, since I wanted to render a specific resolution to the texture. I can probably work around this by using "nearest" sampling and a larger-than-needed texture though.





Scanlines



As far as actual progress goes, I managed to write a fragment shader that adds "scanlines" in real-time! Now, by "scanlines" I just mean alternating black horizontal lines. This is not a perfect CRT emulation, and it doesn't even look terribly good; the screen becomes much darker with all those black lines on it. It is, however, the first step



Here is the shader's code if you are interested. It's intended to run on a single fullscreen quad (pair of triangles) that has a texture stretched across it of the rendered scene. So this would run on a texture after rendering the game to that texture.



Vertex Shader

Code: // Inputs:

// va0 = vertex position

// va1 = vertex UV

//

// Ouputs:

// v0 = UV

// v1 = position in clip space



mov v0, va1

mov v1, va0

mov op, va0



Fragment Shader

Code: // Inputs:

// fs0 = The texture that the game was rendered to.

// v0 = UV

// v1 = position in clip space

// fc0.x = 2

// fc0.y = half the screen's height



tex ft0, v0, fs0<2d, nomip, nearest, clamp>



// Convert the y coordinate from clip-space to screen space and put it in ft1.x

mul ft1.x, v1.y, fc0.y

neg ft1.x, ft1.x



// Figure out if this is an odd-numbered horizontal line or not: ft1.x = y%2

div ft1.x, ft1.x, fc0.x

frc ft1.x, ft1.x

mul ft1.x, ft1.x, fc0.x



// If this is an odd-numbered line, this will turn the color black. Otherwise

// the color will be left unchanged.

mul ft0, ft0, ft1.xxxx



mov oc, ft0



Next up I need to make the phosphors glow, so hopefully I'll be making a new devlog entry soon where I discuss how awesomely well that went



Thanks goes to Somokon in



If you want an excellent reference for AGAL, the official " After starting to learn AGAL 24 hours ago, I've amassed enough "gotchas" that I believe it is time for another edition of The Devil's Details. This time it will focus on Adobe's shader language for Stage3D , AGAL.1.This is a bit of a pain. You can't say simply "add ft0, 5, 10" in order to add 5 + 10 and put the result in ft0; instead, you have to place 5 and 10 into constant registers from your program before you render! This applies to any immediate value, so you also can't do something like "mov oc, [1, 0, 0, 1]" to output a red color, or "mul ft0, v0, 2" to double the value of a varying register. You would have to do something like "add ft0.x, fc0.x, fc0.y" or "mov oc, fc0" or "mul ft0, v0, fc0.x".2.If you are constructing the shader's source code within an ActionScript file by building a stringFor example, do this:not this:Forgetting the line feeds will cause really strange errors that are in no way helpful! For example: "Fragment Write All Components".3.The only supported render type is a triangle list. You can use an index buffer to mitigate the effects of this, so I don't think it will be a show-stopper. It's something to be aware of though.4.If you are rendering to a texture, there is no way to tell it what subregion to render to; the entire texture will be used. This is a little bit of a problem for me, since I wanted to render a specific resolution to the texture. I can probably work around this by using "nearest" sampling and a larger-than-needed texture though.As far as actual progress goes, I managed to write a fragment shader that adds "scanlines" in real-time! Now, by "scanlines" I just mean alternating black horizontal lines. This is not a perfect CRT emulation, and it doesn't even look terribly good; the screen becomes much darker with all those black lines on it. It is, however, the first stepHere is the shader's code if you are interested. It's intended to run on a single fullscreen quad (pair of triangles) that has a texture stretched across it of the rendered scene. So this would run on a texture after rendering the game to that texture.Next up I need to make the phosphors glow, so hopefully I'll be making a new devlog entry soon where I discuss how awesomely well that wentThanks goes to Somokon in this post on the Away3D forums for the modulus technique I'm using.If you want an excellent reference for AGAL, the official " What is AGAL " article is perfect for the job. « Last Edit: September 14, 2013, 08:54:16 PM by InvisibleMan » Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Finished CRT Shader « Reply #26 on: September 19, 2013, 02:01:51 PM »



Sorry for going dark all of a sudden Once I started work on the rest of the shader, I felt like I had to keep going! Fortunately, I think the shader is finished.



I decided to go with a 1:1 ratio of on-screen pixels to phosphor triples rather than a 2:1 ratio; the game is half the size of the mockup I posted earlier, so it should fit on the screen easier. At that scale, you can't make out the individual phosphors, but I think it still looks decent.







I used a screenshot to test the shader, but it also works in real-time Now I need to convert the rendering engine to use Stage3D so that we can see how it will really look in motion!



One interesting thing about this is that the pixels aren't square: they are rectangular. From what I understand, this was to allow for more resolution without upgrading to more expensive arcade hardware. I'm hoping I can find a pixel art tool that allows you to change the pixel geometry, because otherwise everything will have to be drawn long and thin @trentg: Thanks!Sorry for going dark all of a suddenOnce I started work on the rest of the shader, I felt like I had to keep going! Fortunately, I think the shader is finished.I decided to go with a 1:1 ratio of on-screen pixels to phosphor triples rather than a 2:1 ratio; the game is half the size of the mockup I posted earlier, so it should fit on the screen easier. At that scale, you can't make out the individual phosphors, but I think it still looks decent.I used a screenshot to test the shader, but it also works in real-timeNow I need to convert the rendering engine to use Stage3D so that we can see how it willlook in motion!One interesting thing about this is that the pixels aren't square: they are rectangular. From what I understand, this was to allow for more resolution without upgrading to more expensive arcade hardware. I'm hoping I can find a pixel art tool that allows you to change the pixel geometry, because otherwise everything will have to be drawn long and thin Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Hardware/Technique Research and Sprites « Reply #28 on: September 25, 2013, 09:05:55 AM »





GAH! I apparently have trouble keeping this devlog updated on a regular basis; it's been almost a week since the last entry! To remedy this, I'm going to once again try and make "mini-devlogs". This first one is probably going to be a bit long, since a lot has happened. I plan on writing a shorter one next though.



So, I did a bit of research into arcade hardware and general game development techniques from that era. I learned some interesting things, such as 1.



I want the game's engine to be designed with similar aesthetic limitations that developers had to work with in around the 80s. However, this is a delicate balancing act between making a full-on emulator style engine vs. making an engine that is only vaguely reminiscent of that era; the first would be overkill, and the second would cheapen the game.



I'm not going to try and implement too many strictly technical limitations (such as a specific CPU) because I am not entirely sure how I would do it in an optimal way, and it feels like I would drift too far towards the "emulator" side anyways. Obviously a lot of the aesthetic limitations are technical in nature, so again we have a balancing act.



I want to try and get the story and mechanics feeling correct for an 80s era game, which should hopefully be a bit less problematic than technical/aesthetic limitations.



I debated working on the backgrounds system first, but I think it might be easier, and cooler , to get sprites working. It appears as though games of that era used a tilemap system even for the sprites; so those large sprites are actually a tilemap of smaller sprite "chunks". I don't think I will be directly emulating this aspect, since there would be little point. The sprites should probably be designed with this in mind though.



1. Apparently it's what we now call a "tilemap". @trentg Thanks again! I don't remember if I mentioned this in the devlog or not, but I plan to add an option to turn the effect off. This way if it's annoying to the player, he can play the game without itGAH! I apparently have trouble keeping this devlog updated on a regular basis; it's been almost a week since the last entry!To remedy this, I'm going to once again try and make "mini-devlogs". This first one is probably going to be a bit long, since a lot has happened. I plan on writing a shorter one next though.So, I did a bit of research into arcade hardware and general game development techniques from that era. I learned some interesting things, such as how scrolling worked hardware-level information , and what a "name table" is/was I want the game's engine to be designed with similarlimitations that developers had to work with in around the 80s. However, this is a delicate balancing act between making a full-on emulator style engine vs. making an engine that is only vaguely reminiscent of that era; the first would be overkill, and the second would cheapen the game.I'm not going to try and implement too many strictlylimitations (such as a specific CPU) because I am not entirely sure how I would do it in an optimal way, and it feels like I would drift too far towards the "emulator" side anyways. Obviously a lot of the aesthetic limitations are technical in nature, so again we have a balancing act.I want to try and get theandfeeling correct for an 80s era game, which should hopefully be a bit less problematic than technical/aesthetic limitations.I debated working on the backgrounds system first, but I think it might be easier, and cooler, to get sprites working. It appears as though games of that era used a tilemap system even for the sprites; so those large sprites are actually a tilemap of smaller sprite "chunks". I don't think I will be directly emulating this aspect, since there would be little point. The sprites should probably be designed with this in mind though. Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Live Streaming 7:12 Pixel Art « Reply #29 on: September 26, 2013, 09:37:58 AM »



However, it is difficult to draw with square pixels and make them "rectangular". I was trying to find a pixel art program (or any kind of drawing program!) that supported changing the pixel aspect ratio, but other than Photoshop (which is too expensive for our budget) I couldn't find anything. The closest I got was



Fortunately I discovered a workaround: Using my graphics drivers, I can define a custom resolution (746x1024 in this case) which forces the pixels to be rectangular! This makes the "rectangular" pixel art look relatively normal, so I can draw easier.



I'm live streaming the pixel art that I'm doing, so if you want to watch this wacky art style, please head on over to The pixels need to be rectangular rather than square. This was originally a trick to get more resolution out of the same equipment; increase the amount of data per scanline without needing additional scanlines.However, it is difficult to draw with square pixels and make them "rectangular". I was trying to find a pixel art program (or any kind of drawing program!) that supported changing the pixel aspect ratio, but other than Photoshop (which is too expensive for our budget) I couldn't find anything. The closest I got was grafx2 , but it only supported 1:1, 1:2, 2:2, and other such ratios; I need a pixel aspect ratio of 7:12.Fortunately I discovered a workaround: Using my graphics drivers, I can define a custom resolution (746x1024 in this case) which forces the pixels to be rectangular! This makes the "rectangular" pixel art look relatively normal, so I can draw easier.I'm live streaming the pixel art that I'm doing, so if you want to watch this wacky art style, please head on over to http://www.twitch.tv/invisibleman6 . I'll see you there! Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer New Sprite « Reply #30 on: September 27, 2013, 08:09:20 AM »





It's technically a 2x2 tilemap of 16x16 tiles The rendering engine doesn't accept tilemaps for sprites, but it's good to keep it in mind.



In my initial attempts at rendering that sprite, it came out looking like this:





Now, it might look like the sprite I posted above (except with blank scanlines), but that is exactly the problem: It was supposed to be compressed vertically, but it wasn't. It looks a bit long, and the wings look a bit short, beccause it was drawn with the expectation that it would be compressed... So I definitely need to fix something. Here is the player's warplane sprite that I drew yesterday:It's technically a 2x2 tilemap of 16x16 tilesThe rendering engine doesn't accept tilemaps for sprites, but it's good to keep it in mind.In my initial attempts at rendering that sprite, it came out looking like this:Now, it might look like the sprite I posted above (except with blank scanlines), but that is exactly the problem: It was supposed to be compressed vertically, but it wasn't. It looks a bit long, and the wings look a bit short, beccause it was drawn with the expectation that it would be compressed... So I definitely need to fix something. Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer Wrong Pixel Aspect Ratio « Reply #31 on: September 27, 2013, 04:49:41 PM » Rather than 7:12 I actually need 6:5 and a screen resolution of 1067x1024 for spriting. So the rendering wasn't bugged; the sprite was wrong.



This of course means that I will need to redraw the sprite. But I suppose that's not too bad; I get better at it each time Well, I found the problem: Apparently the pixel aspect ratio I calculated was incorrectRather than 7:12 I actually need 6:5 and a screen resolution of 1067x1024 for spriting. So the rendering wasn't bugged; the sprite was wrong.This of course means that I will need to redraw the sprite. But I suppose that's not too bad; I get better at it each time Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer New Sprite with the Correct Pixel Aspect Ratio « Reply #32 on: September 30, 2013, 10:02:02 AM »





And here is the actual sprite:





This is with a 6:5 pixel aspect ratio, which is apparently correct Now I just need to get a proper sprite system in place (there isn't much of a "system" at the moment). I should probably also investigate how to detect keyboard input in AS3 without using FlashPunk... It would make running these tests easier, assuming getting the input itself isn't difficult.



I'm also considering adding a "curve" to the CRT effect, and rounded corners... I might experiment with that next actually. The new sprite is done! Here is the in-game screenshot:And here is the actual sprite:This is with a 6:5 pixel aspect ratio, which is apparently correctNow I just need to get a proper sprite system in place (there isn't much of a "system" at the moment). I should probably also investigate how to detect keyboard input in AS3 without using FlashPunk... It would make running these tests easier, assuming getting the input itself isn't difficult.I'm also considering adding a "curve" to the CRT effect, and rounded corners... I might experiment with that next actually. Logged Twitter - Facebook - YouTube

karlozalb







Do or do not.There is no try.





Level 5Do or do not.There is no try. Re: Codename: Warplane - Classic Arcade-Style WW2 SHMUP « Reply #34 on: October 02, 2013, 09:22:41 AM » (It's an entire world to discover).



P.S. I'm following this from time ago Looks cool What will you do to simulate the CRT curvature? I'm fighting against shaders for my game too(It's an entire world to discover).P.S. I'm following this from time agoLooks cool Logged

ITS_Mike







Programmer





Level 3Programmer Re: Codename: Warplane - Classic Arcade-Style WW2 SHMUP « Reply #35 on: October 02, 2013, 09:34:26 AM »



@karlozalb: I'm not entirely sure; I haven't researched how people commonly do the effect. I'm thinking something along the lines of sampling from the texture by applying a sin() and cos() weight to the texture coordinates. And thanks! It's good to know that people have been following the project @trentg: Thanks!@karlozalb: I'm not entirely sure; I haven't researched how people commonly do the effect. I'm thinking something along the lines of sampling from the texture by applying a sin() and cos() weight to the texture coordinates. And thanks! It's good to know that people have been following the project Logged Twitter - Facebook - YouTube

ITS_Mike







Programmer





Level 3Programmer A Mass of Sprites « Reply #36 on: October 07, 2013, 08:44:39 AM »





2,628 sprites are being rendered to random locations every frame at 60 frames per second. This unfortunately drops to 30 FPS on our current low-end target machine, but the game should still be playable at that rate I hope.



I'm using a single vertex buffer to store the information for every sprite. This vertex buffer is being uploaded to the GPU every frame before the sprites are rendered. A single sprite is made up of two triangles to form a rectangle; triangle strips are not supported by Stage3D. If anyone has some tips on how to make this run faster, please let me know I've been working on getting multiple sprites to render at once. Here is the result2,628 sprites are being rendered to random locations every frame at 60 frames per second. This unfortunately drops to 30 FPS on our current low-end target machine, but the game should still be playable at that rate I hope.I'm using a single vertex buffer to store the information for every sprite. This vertex buffer is being uploaded to the GPU every frame before the sprites are rendered. A single sprite is made up of two triangles to form a rectangle; triangle strips are not supported by Stage3D. If anyone has some tips on how to make this run faster, please let me know Logged Twitter - Facebook - YouTube