MayDay Posted January 2, 2017 Share Posted January 2, 2017 Looks good- Different character mockup that might help? If you give me some different design parameters, I'd happily redesign them. Red indicates where you would currently need missile to fill in. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 3, 2017 Share Posted January 3, 2017 shifting 2x or 4x players left/right on every scanline (reply #16) can be used to create smoother looking, and wider objects. Extra width could be useful for extending the arms. Thanks for the tip. Making it wider would complicate the palette switch timing further. It's probably best to avoid that. Using a 1 pixel shift to smooth out the edges should work nicely. I'll add support for moving players. Looks good- Different character mockup that might help? If you give me some different design parameters, I'd happily redesign them. Red indicates where you would currently need missile to fill in. The original mockup was pretty close to fitting the constraints. Most of the graphical glitches are from me messing up the data as coded it up. There are a lot of constraints to deal with. Here are the main ones. The player and missile must not overlap. Missiles must be sized 0, 1, 2, 4, or 8 pixels wide. Players must be double wide. (This could probably be changed if needed, but I doubt it would gain much) Missiles can only be moved 7 pixels in either direction between each row. (The revised mockup obeys this rule because the 10 pixel move is split across 2 rows) The easiest way for you to verify the graphics would be to input the data directly into the source code and see what it looks like in Stella. Let me make a few more changes and then I'll push it all to GitHub. You'll need to have Visual Studio 2013 or newer installed so you can build and run the code. Everything is written in C. I can take care all of the kernel code if someone else can implement the game logic and design all the graphics. This should be able to run on a harmony cart once the BUS driver becomes available. If not it will need to utilize the new cartridge I designed. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 4, 2017 Share Posted January 4, 2017 Added support for player movement to smooth out graphics. Just adjusting the top of the head makes a nice improvement. Also, after thinking about how to implement the color changes I don't think it will be a problem to use the player movement to extend the sprite horizontally for kicking and punching. 1 Quote Link to comment Share on other sites More sharing options...
moycon Posted January 4, 2017 Share Posted January 4, 2017 Amazing stuff! 1 Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 4, 2017 Share Posted January 4, 2017 (edited) I've been working on some different arenas- all of these are playfield only with maximum two colors per scanline. Three are reflected playfields, The Pit is a repeating playfield, but the clouds could easily be reflected or even just removed. I think with 8-10 characters, 4 arenas would be a good number. I also redesigned them so that there would be no side to side scrolling. Dungeon, Throne Room, Outside Throne, and The Pit. Quick Edit- The Black in the dungeon would probably need changed to a dark gray so as to still be able to see some of the characters against it. Edited January 4, 2017 by MayDay 3 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 4, 2017 Share Posted January 4, 2017 Those look great. I can't wait to get them converted and into the engine. The kernel supports PF scrolling. It can even scroll different sections at different rates to create a parallax effect. The overall width in PF pixels can be as much as 128. Keep in mind that the left 2 PF pixels are always hidden by the HMOVE bars. Leave the left most PF pixel off in all your mockups so the image converter can identify which is background and which is PF. There isn't really any constraint or ROM space. So feel free to make as many arenas as you'd like. I'll build a converter that is run as a prebuild step. That way all that has to be done is to drop the image files into the "assets/arena/" folder and click run. Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 5, 2017 Share Posted January 5, 2017 A few things- 1.) I played around with a character selection screen tonight. I think I finally figured out a good way to do it, but I will have to finish it tomorrow. 2.) I pulled out my Sega Classic console and played the original MK for a while. It has six total arenas, but the other two don't translate that well. I think four arenas is a good number anyway. Because the characters we're making will be smaller, I also don't think scrolling is necessary. I kind of like the solid screen, and hopefully that would free up some cycles for the gameplay. 3.) What would this be called? I would suggest MK2600 for the title screen since "MK" doesn't specifically violate a copyright. See below. 4.) We'll need to decide what controls we want to use. After we know that, I can start trying to put together more specific sprite animations. 5.) For the record not everything shown in those mockups are original. The colored sky on the courtyard is from an existing game, I forget which one. The clouds on the pit is from Pole Position. The skeleton in the dungeon was heavily inspired by the one Pac Man Red created in the free sprite thread. 6.) I think this game could turn out really spectacular! Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 5, 2017 Share Posted January 5, 2017 I also don't think scrolling is necessary. I kind of like the solid screen, and hopefully that would free up some cycles for the gameplay. Don't worry about freeing up cycles. This game will be written entirely in C and is going to run on the ARM processor. I'll post a video once I get the parallax done. I'm pretty sure you'll agree with using scrolling once you see it in action. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 5, 2017 Share Posted January 5, 2017 The VCS uses pixels that are wider than they are tall. Can you start sizing your mock-ups as 1280x960? In other words a single width pixel should be drawn as an 8x5 rectangle and a quad or PF pixel should be a 32x5 rectangle. This will make the aspect ratio match what the real system and TV display. Quote Link to comment Share on other sites More sharing options...
Thomas Jentzsch Posted January 5, 2017 Share Posted January 5, 2017 Can't see Mayday's pictures again. Quote Link to comment Share on other sites More sharing options...
sn8k Posted January 5, 2017 Share Posted January 5, 2017 Will this support fatalities as well? Uppercut off bridge into spikes? Reptile and smoke should be hidden. Finishing perfect with fatality on first stage with perfect on bridge plus spike fatality triggers pit fight with reptile. Make him super hard. Double flawless plus fatality gets you to smoke Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 6, 2017 Share Posted January 6, 2017 The VCS uses pixels that are wider than they are tall. Can you start sizing your mock-ups as 1280x960? In other words a single width pixel should be drawn as an 8x5 rectangle and a quad or PF pixel should be a 32x5 rectangle. This will make the aspect ratio match what the real system and TV display. I can, but it will take me a while to convert them. I've actually been making images that are only 192x160, then just taking a screenshot of them enlarged to post. Making them small makes it a lot easier to both fill in and keep track of the correct number of pixels. If it helps, I could create them at 192x240, and that should correct the aspect ratio problem. That would be a lot faster if that works? I'm going to try and finish up the character selection screen, then I'll begin converting everything over. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 6, 2017 Share Posted January 6, 2017 I can, but it will take me a while to convert them. I've actually been making images that are only 192x160, then just taking a screenshot of them enlarged to post. Making them small makes it a lot easier to both fill in and keep track of the correct number of pixels. If it helps, I could create them at 192x240, and that should correct the aspect ratio problem. That would be a lot faster if that works? I'm going to try and finish up the character selection screen, then I'll begin converting everything over. You should continue to make them 160x192 and enlarging them to post. There's no need to convert anything you've already done. I was just recommending you resize any new mockups to 1280x960 (width*8, height*5) instead of the size you've been resizing them to. Either way I'm going to build a converter tool which will convert them to something the code can consume. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 6, 2017 Share Posted January 6, 2017 PF Converter is functional. 3 Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 6, 2017 Share Posted January 6, 2017 Looks good! Some of the colors appear to be a little bit off, but that should be pretty easy to fix, it appears it is grabbing all of the data correctly. I've also been messing around with the selection screen to no avail. I was trying to do it strictly with the playfield, and thought I had it figured out at one point, but it didn't look that good when I was done. As an alternative, would it be possible to use the sprites in a straight downward line? The yellow / blue lines you see would be the player highlighted selection. If you wanted to hide a character or two, you could just move them to the bottom. 2 Quote Link to comment Share on other sites More sharing options...
Papa Posted January 6, 2017 Share Posted January 6, 2017 I totally love that title screen. It's better than the original by far. I often cringe at BMP mock-ups as multicolored sprites that layer like this are not the easiest thing to do on the VCS. So, is someone really programming this? Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 6, 2017 Share Posted January 6, 2017 Will this support fatalities as well? Uppercut off bridge into spikes? Reptile and smoke should be hidden. Finishing perfect with fatality on first stage with perfect on bridge plus spike fatality triggers pit fight with reptile. Make him super hard. Double flawless plus fatality gets you to smoke I'm not sure how we would implement vertical spikes. The Playfield pixels are too wide to make them pointy. Maybe the RESP trick would work. I remember someone making a circus game that has balloons repeated across the full width of the screen. So do the same thing, but draw spikes instead of balloons. Then the only problem is drawing the body hitting the spikes. Unlockable characters sounds like a good plan. Should definitely add that. Looks good! Some of the colors appear to be a little bit off, but that should be pretty easy to fix, it appears it is grabbing all of the data correctly. I've also been messing around with the selection screen to no avail. I was trying to do it strictly with the playfield, and thought I had it figured out at one point, but it didn't look that good when I was done. As an alternative, would it be possible to use the sprites in a straight downward line? The yellow / blue lines you see would be the player highlighted selection. If you wanted to hide a character or two, you could just move them to the bottom. We'll need to eventually sync up the palettes we're using so the conversions are more accurate. There should probably be a NSTC to PAL conversion table too. Right now I've just been assuming everything is NSTC since that's all we have here. I think with enough spacing between the two columns of players we can get a full selection box around them instead of lines above and below. Need to start a backlog so I keep track of everything left to do. I totally love that title screen. It's better than the original by far. I often cringe at BMP mock-ups as multicolored sprites that layer like this are not the easiest thing to do on the VCS. So, is someone really programming this? Yes. I've been creating new kernels and tools to attempt to keep up with all of MayDay's mockups in an actual Atari game. The screenshots I've been posting are actually running in a modified version of Stella that supports my new bus-stuffing API. Hopefully someone will volunteer to help out with the actual game logic. If not I'll get to it eventually. Since everything is being written in C it shouldn't take that long to complete. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 6, 2017 Share Posted January 6, 2017 There should probably be a NSTC to PAL conversion table too. Right now I've just been assuming everything is NSTC since that's all we have here. I've been coding up my projects to use colors stored in lookup tables in RAM. Doing it this way lets you release a single ROM and the user can select* NTSC, PAL or SECAM at run time. I don't change the screen size so those are actually PAL60 and SECAM60 in my games. Feel free to adopt these routines if you find them useful. This bit of code in the menu updates lookup tables based on what the user's selected: // Convert colors based on MM_TV_TYPE for(i=0;i<MAIN_MENU_CLR_SIZE;i++) gMenuColors[i] = ColorConvert(gMenuColors[i]); // Convert object colors based on MM_TV_TYPE // -2 so the RadarColors also get updated for(i=-2;i<OBJECT_COLOR_SIZE;i++) queue[OBJECT_COLORS + i] = ColorConvert(ddrom[OBJECT_COLORS+i]); My tables are defined in the 6507 source using these constants: ; Color constants. Only need NTSC, will do on the fly conversion for ; PAL and SECAM GREY = $00 YELLOW = $10 ORANGE = $20 RED_ORANGE = $30 RED = $40 PURPLE = $50 VIOLET = $60 BLUE = $80 GREEN = $C0 WHITE = $0E The tables start out like this for the menu: MainMenuColors: .byte GREEN + 4 ; PF color, the station inside the O ds 31, VIOLET + 2 ds 6, PURPLE + 2 ds 6, RED + 4 ds 6, RED + 6 ds 6, RED + 8 ds 6, RED_ORANGE + 8 ds 6, RED_ORANGE + 10 ds 6, RED_ORANGE + 12 ds 6, YELLOW + 12 ds 11, YELLOW + 14 .byte 0 MenuOptionGreen: .byte GREEN + 8, BLUE + 8 .byte GREEN +10, BLUE +10 .byte GREEN +12, BLUE +12 .byte GREEN +14, BLUE +14 .byte GREEN +14, BLUE +14 .byte GREEN +12, BLUE +12 .byte GREEN +10, BLUE +10 .byte GREEN + 8, BLUE + 8 MenuOptionRed: .byte RED + 8, BLUE + 8 .byte RED +10, BLUE +10 .byte RED +12, BLUE +12 .byte RED +14, BLUE +14 .byte RED +14, BLUE +14 .byte RED +12, BLUE +12 .byte RED +10, BLUE +10 .byte RED + 8, BLUE + 8 MenuOptionGrey: .byte GREY+4, GREY+4 ; 0 .byte GREY+4, GREY+4 ; 1 .byte GREY+4, GREY+4 ; 2 .byte GREY+4, GREY+4 ; 3 .byte GREY+4, GREY+4 ; 4 .byte GREY+4, GREY+4 ; 5 .byte GREY+4, GREY+4 ; 6 .byte GREY+4, GREY+4 ; 7 MenuSelectedColor: .byte GREY+6, GREY+ 8; 0 .byte GREY+6, GREY+10; 1 .byte GREY+6, GREY+12; 2 .byte GREY+6, GREY+14; 3 .byte GREY+6, GREY+14; 4 .byte GREY+6, GREY+12; 5 .byte GREY+6, GREY+10; 6 .byte GREY+6, GREY+ 8; 7 StartColor: .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte WHITE, WHITE .byte 0, 0 MainMenuColorsSize = * - MainMenuColors MainMenuGraphicsSize = * - MainMenuGraphics and like this for the objects, the last two entries in RadarControl are part of the color conversion, the first three values change due to gameplay events: RadarControl: .byte $C8 ; condition color .byte HMOVE_0 ; BallXadjust .byte $18 ; player1, formation color .byte $48 ; player0, enemy color .byte $C8 ; player1, station color ; must directly follow RadarControl so radar colors get updated based on TV-Type ObjectColors: .byte $28 ; 0 asteroid - orange .byte $88 ; 1 mine - blue .byte $0c ; 2 ship - white, subtract 2 due to lumaboost .byte $58 ; 3 itype - pink .byte $ac ; $b8 ; 4 ptype - cyan .byte $48 ; $38 ; 5 etype - reddish orange .byte $18 ; 6 spy - yellow .byte $c8 ; 7 station -green .byte $c4 ; 8 condition green .byte $1A ; 9 condition yellow .byte $44 ; 10 condition red .byte $38 ; 11 itype lead - orange .byte $58 ; 12 ptype lead - pink .byte $96 ; $88 ; 13 etype lead - blue .byte $48 ; 14 radar enemy ObjectColorSize = * - ObjectColors If conversion is required the routines use NTSC to PAL conversion values posted by SeaGtGruff, or SECAM values I worked up: const unsigned char NTSCtoPAL[16] = { // SeaGtGruff's conversion values from this post at AtariAge: // http://www.atariage.com/forums/topic/165424-modify-colour-palette/page__p__2043124#entry2043124 0x00, 0x20, 0x20, 0x40, 0x60, 0x80, 0xa0, 0xc0, 0xd0, 0xb0, 0x90, 0x70, 0x50, 0x30, 0x30, 0x20 }; int ColorPAL(int color) { return NTSCtoPAL[color>>4] + // chroma value (color & 0x0f); // luma value } const unsigned char NTSCtoSECAM[16] = { 0x0e, // 0 = white e = white 0x0c, // 1 = yellow c = yellow 0x0c, // 2 = yellowish orange c = yellow 0x04, // 3 = reddish orange 4 = red 0x04, // 4 = red 4 = red 0x06, // 5 = reddish purple 6 = purple 0x06, // 6 = purple 6 = purple 0x06, // 7 = bluish purple 6 = purple 0x02, // 8 = blue 2 = blue 0x02, // 9 = blue 2 = blue 0x0a, // a = bluish cyan a = cyan 0x0a, // b = cyan a = cyan 0x08, // c = green 8 = green 0x08, // d = green 8 = green 0x08, // e = olive green 8 = green 0x0c // f = brown c = yellow }; int ColorSECAM(int color) { if (color < 2) return 0; // return black for 0 or 1 else return NTSCtoSECAM[color>>4]; } int ColorConvert(int color) { if (MM_TV_TYPE == PAL) return ColorPAL(color); else if (MM_TV_TYPE == SECAM) return ColorSECAM(color); else return color; } * somebody, possibly you, suggested it would be possible to use timing on the ARM to autodetect NTSC or PAL/SECAM so the user wouldn't have to select it. I haven't experimented with that yet. I don't believe it'd be possible to autodetect SECAM vs PAL. Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 6, 2017 Share Posted January 6, 2017 Just realized that doesn't have all of the NTSC color constants that I currently use: BLACK = $00 WHITE = $0E GREY = $00 YELLOW = $10 ORANGE = $20 BROWN = $30 RED = $40 PURPLE = $50 VIOLET = $60 INDIGO = $70 BLUE = $80 BLUE2 = $90 TURQUOISE = $A0 CYAN = $B0 GREEN = $C0 YELLOW_GREEN = $D0 OCHRE_GREEN = $E0 OCHRE = $F0 Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted January 6, 2017 Share Posted January 6, 2017 I was thinking we just need to define a 256 byte array which maps each NTSC color value to the closest PAL color value. In pal mode just lookup the pal color anytime a write to one of the color register occurs. That way the game code doesn't even need to be nstc/pal aware 1 Quote Link to comment Share on other sites More sharing options...
sn8k Posted January 6, 2017 Share Posted January 6, 2017 Actual mortal kombat doesn't have spike animations. They just drop onto the floor of the spiked area. Nothing fancy was done. How ever if you were to insert a standard animation for all characters where once they hit spikes they become a contorted mess of broken bones and actually get stuck to them. However considering this is somewhat hard to pull off, I would just go for standard drop onto floor of spiked area, the way it currently is on genesis. Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 7, 2017 Share Posted January 7, 2017 (edited) I kept messing around with the selection screen, and I'm a lot closer to something I like now. The two corners will require both sprites, as will the logo in the middle. Otherwise this is all playfield/background. There should be space around each character to fit a playfield box when selecting. I have it as layers, so I can also separate playfield and sprites if you want to mock it up. Edit- Actually just went ahead and removed the sprites so you would already have it. Edited January 7, 2017 by MayDay Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 7, 2017 Share Posted January 7, 2017 Game Selection Screen- pretty simple really. With and without sprites, which are 42 pixels at widest spot. 1 Quote Link to comment Share on other sites More sharing options...
+SpiceWare Posted January 7, 2017 Share Posted January 7, 2017 I was thinking we just need to define a 256 byte array which maps each NTSC color value to the closest PAL color value. In pal mode just lookup the pal color anytime a write to one of the color register occurs. That way the game code doesn't even need to be nstc/pal aware My understanding is the bit shifting is "free" for at least some of the instructions in the ARM processor, so you might be able to halve the lookup table by doing this: PAL_Color[NTSC_Color >> 1] Quote Link to comment Share on other sites More sharing options...
MayDay Posted January 7, 2017 Share Posted January 7, 2017 Bottom of the Pit. Ideally with 3 rows of spikes, and more realistically with 2 rows. Would need to redesign the original Pit to match this too. 1 Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.