+DZ-Jay Posted November 12, 2014 Share Posted November 12, 2014 The consensus was a big WTF for the Game Over screen, so here's a new one. And it's animated, so the screenshot doesn't completely do it justice. I'm not 100% sold on the "press any button" - is that sort of text even needed? Is it obvious to people to just press something to continue? And if so - buttons, disc, or both? I could just center the goat at the bottom. Also, there will be some sort of sad song played when the screen comes up. Haven't written that yet. Looks awesome! I like it a lot. I'd say, center the goat at the bottom and don't bother with the "press any key" message. -dZ. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted November 12, 2014 Share Posted November 12, 2014 I finally noticed the reason why the middle seasons seem to speed up and slow down. It seems that the speed is not timer-based but score-(or nom)-based. So, after I eat the single item that brings the meter up to the threshold, the items on the screen immediately accelerate, wherever they are; and if I miss one more item at that precise moment and the meter goes down, the items decelerate immediately. This behaviour seems a bit odd, especially since it happens in "real time" and affects all items currently on the screen (including the goat itself!) as opposed to waiting for the next set of items to be thrown at the new velocity. There should be a better way that is less weird, I'll try to think of some ideas. -dZ. Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted November 12, 2014 Share Posted November 12, 2014 Almost as bad as confusing bytes with words!arent you like the people in the matrix? I would think by now you can look at scrolling code and see a beautiful redhead or something... Quote Link to comment Share on other sites More sharing options...
intvnut Posted November 12, 2014 Share Posted November 12, 2014 I finally noticed the reason why the middle seasons seem to speed up and slow down. It seems that the speed is not timer-based but score-(or nom)-based. So, after I eat the single item that brings the meter up to the threshold, the items on the screen immediately accelerate, wherever they are; and if I miss one more item at that precise moment and the meter goes down, the items decelerate immediately. This behaviour seems a bit odd, especially since it happens in "real time" and affects all items currently on the screen (including the goat itself!) as opposed to waiting for the next set of items to be thrown at the new velocity. There should be a better way that is less weird, I'll try to think of some ideas. Astrosmash does almost the same thing. However, the objects currently on the screen at the time of the change keep their current momentum and only new objects take on the new speed (whether it's faster or slower). Quote Link to comment Share on other sites More sharing options...
intvnut Posted November 12, 2014 Share Posted November 12, 2014 arent you like the people in the matrix? I would think by now you can look at scrolling code and see a beautiful redhead or something... Hah! I'm more likely to see a goat, at this point. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted November 13, 2014 Share Posted November 13, 2014 Astrosmash does almost the same thing. However, the objects currently on the screen at the time of the change keep their current momentum and only new objects take on the new speed (whether it's faster or slower). That's fine. The weird thing is when the objects already on the screen speed up and then slow down within a few frames--even the goat in mid-stride. Quote Link to comment Share on other sites More sharing options...
freewheel Posted November 13, 2014 Author Share Posted November 13, 2014 Astrosmash does almost the same thing. However, the objects currently on the screen at the time of the change keep their current momentum and only new objects take on the new speed (whether it's faster or slower). Then this is another example where I'm coding too much and not playing enough. I would have sworn that Astrosmash objects speed up mid-flight. I think timer-based is more and more likely at this point. I still like the idea of losing points (NOM) for missing things, a la Astrosmash, but there won't be slowdowns. Remember, this mechanism was in place from the get-go, because the game was going to be one long stage like this. Now that it's split up, I think it's time to really re-think how it all works. So - you guys toss suggestions around. Also the farmer changes color based on the speed (and goes through like 6 or 7 "levels"). Does anyone find that helpful? Annoying? Pointless? Amazing? Oh and DZ: your bee idea is in the works, but not in the way you're thinking. I wanna play around with the look first; it's great "on paper" (PSP) but I wanna see what it's like animated. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted November 13, 2014 Share Posted November 13, 2014 I think timer-based is more and more likely at this point. I still like the idea of losing points (NOM) for missing things, a la Astrosmash, but there won't be slowdowns. Remember, this mechanism was in place from the get-go, because the game was going to be one long stage like this. Now that it's split up, I think it's time to really re-think how it all works. I don't think you need to go timer-based, just set a flag when the points cross the threshold and have the next set of objects start with the adjusted velocity. So - you guys toss suggestions around. Also the farmer changes color based on the speed (and goes through like 6 or 7 "levels"). Does anyone find that helpful? Annoying? Pointless? Amazing? Didn't notice. I guess that tells you something... Oh and DZ: your bee idea is in the works, but not in the way you're thinking. I wanna play around with the look first; it's great "on paper" (PSP) but I wanna see what it's like animated. Coolio! -dZ. Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 12, 2014 Author Share Posted December 12, 2014 It's baaaaaaaaaaaaaaaack! Real life got in the way of a lot of things lately. And this game is far enough along that it's tricky to implement quick and easy things, so I needed some uninterrupted time to even open the code again. Anyway, some changes: 1. Cleaned up "game over" screen. Still need music for this. 2. A shit-ton of code cleanup to take advantage of IntyBASIC 1.0 additions. Mostly involving printing large numbers, which you guys won't even see in this ROM yet. That little treat is actually why there was no update for a couple of weeks - I'm working on a completely new addition here. I'm still not satisfied with the mechanics but it's coming closer. Oh, and I removed over a thousand lines of commented code (old code, for the most part). Freed a nice bit of ROM space and variables, too. Hopefully I haven't broken anything in the process. This was a large re-write of some important sections. 3. The issue with objects speeding up and slowing down mid-flight - I think I have it solved. Now, the game will still speed up as you fill the NOM meter (and slow down if you miss enough things to reduce the meter). However objects will maintain their velocity from the time they're thrown until they go away. I know this was a real stickler for DZ, and I have to agree with you. It was definitely "programmer logic" in the sense that it seemed OK while writing it, but it's confusing as a game mechanic. It should now behave much like Astrosmash. 4. Some hokey Intellivoice additions. Some will be obvious, some less so. Curious on general feedback for those you discover. One is definitely staying; I spent countless hours trying to do this with the PSG and am SOOO happy that the Intellivoice gives me a reasonable facsimile of what I was aiming for. I think that's it - the big change is really the speedup/slowdown logic. I'm interested if it seems to make more sense now, or if I've introduced bugs. I've play-tested a fair bit but like everything, you guys really find the edge cases. Oh, and the general game mechanics have not changed. Winter is still difficult to the point of tedium. I'll work on game balancing .. eventually. Still have a lot of stuff I want to do for the new secret addition. It involves bees. goat.rom 5 Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 13, 2014 Author Share Posted December 13, 2014 (edited) OK, feedback time. Just on some screenshots. Tarzilla did a fantastic job making a very different title screen, and I spent the morning tweaking it some. I forgot that the damn goat is only 3 MOBs but actually uses 5 cards. So I need to steal from Peter to pay Paul and all of that... anyway - what do you guys think? The old screen has the darker sky, the new one is more "natural" for daylight. I think tarzilla did a frigging bang-up job on the mountains. It's pretty tricky to make this kind of art with the 2 color card limitation but I'm pretty impressed. You have to look a bit to even see the boundaries. Unfortunately I am absolutely maxed on MOBs and GRAM. I might be able to squeeze one more GRAM card, possibly 2 if I sacrifice something, but there's no point unless it's to fix a really horrible blockiness. Edited December 13, 2014 by freeweed 3 Quote Link to comment Share on other sites More sharing options...
pimpmaul69 Posted December 13, 2014 Share Posted December 13, 2014 OK, feedback time. Just on some screenshots. Tarzilla did a fantastic job making a very different title screen, and I spent the morning tweaking it some. I forgot that the damn goat is only 3 MOBs but actually uses 5 cards. So I need to steal from Peter to pay Paul and all of that... anyway - what do you guys think? The old screen has the darker sky, the new one is more "natural" for daylight. I think tarzilla did a frigging bang-up job on the mountains. It's pretty tricky to make this kind of art with the 2 color card limitation but I'm pretty impressed. You have to look a bit to even see the boundaries. friggin sweet looking Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted December 13, 2014 Share Posted December 13, 2014 OK, feedback time. Just on some screenshots. Tarzilla did a fantastic job making a very different title screen, and I spent the morning tweaking it some. I forgot that the damn goat is only 3 MOBs but actually uses 5 cards. So I need to steal from Peter to pay Paul and all of that... anyway - what do you guys think? The old screen has the darker sky, the new one is more "natural" for daylight. I think tarzilla did a frigging bang-up job on the mountains. It's pretty tricky to make this kind of art with the 2 color card limitation but I'm pretty impressed. You have to look a bit to even see the boundaries. Unfortunately I am absolutely maxed on MOBs and GRAM. I might be able to squeeze one more GRAM card, possibly 2 if I sacrifice something, but there's no point unless it's to fix a really horrible blockiness. Except you probably don't need 5 simultaneous cards for the goat. I'm assuming 3 for the standing goat, then you need two more cards for change to the legs. Instead of wasting a total of 5 cards for the two frames of animation, you can redefine the leg cards on the fly as the frames don't need to be part of the inital 64 gram definition.... If the legs are cards 62 and 63, just define them each frame as required. Define 62,2,Goat_Legs1 then next frame Define 62,2,Goat_Legs2 Where Goat_Legs1: Bitmap "01000010" etc rem rest of the definition for the two cards for the legs... Goat_legs2: Bitmap "0001100" etc rem rest of the definition for the two cards for the legs... Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 13, 2014 Author Share Posted December 13, 2014 (edited) The standing goat is actually made up of 5 cards - it has nothing to do with the animation. In fact the animation on the title screen doesn't even change the MOB at all - just its position. It's a 16x16 image with no pixel doubling, plus the horns/eye. Edited December 13, 2014 by freeweed Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted December 13, 2014 Share Posted December 13, 2014 OK, feedback time. Just on some screenshots. Tarzilla did a fantastic job making a very different title screen, and I spent the morning tweaking it some. I forgot that the damn goat is only 3 MOBs but actually uses 5 cards. So I need to steal from Peter to pay Paul and all of that... anyway - what do you guys think? The old screen has the darker sky, the new one is more "natural" for daylight. I think tarzilla did a frigging bang-up job on the mountains. It's pretty tricky to make this kind of art with the 2 color card limitation but I'm pretty impressed. You have to look a bit to even see the boundaries. Unfortunately I am absolutely maxed on MOBs and GRAM. I might be able to squeeze one more GRAM card, possibly 2 if I sacrifice something, but there's no point unless it's to fix a really horrible blockiness. Looks awesome. I only have one suggestion (of course!): On the left-most mountain peak, you should remove the bottom two white pixels. They form a nice snow pattern, but they also delineate the boundary of the tiles, which is made more obvious by the horizontal black line on its right side. Removing those two pixels should smooth it out a bit and blur the tile boundary. See below. <- Before <- After 1 Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted December 13, 2014 Share Posted December 13, 2014 Oh, and by the way, I forgot to say.... YAY!!! Mountains! Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 13, 2014 Author Share Posted December 13, 2014 Looks awesome. I only have one suggestion (of course!): On the left-most mountain peak, you should remove the bottom two white pixels. They form a nice snow pattern, but they also delineate the boundary of the tiles, which is made more obvious by the horizontal black line on its right side. Removing those two pixels should smooth it out a bit and blur the tile boundary. See below. goatnom-before.png <- Before goatnom-after.png <- After Easy to fix. Can't decide which I like better - the before has an obvious horizontal line. But the after makes the next tile more obviously blocky. It kinda draws attention to it - no? 1 Quote Link to comment Share on other sites More sharing options...
+Tarzilla Posted December 13, 2014 Share Posted December 13, 2014 (edited) Oh, and by the way, I forgot to say.... YAY!!! Mountains! Well, I did use this for reference because of the music on the title page... I like my clouds better tho... Edited December 13, 2014 by Tarzilla 1 Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 13, 2014 Author Share Posted December 13, 2014 (edited) DZ's suggestion, plus a couple of pixels adjusted on some other snow to hide some lines: Edited December 13, 2014 by freeweed 3 Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 13, 2014 Author Share Posted December 13, 2014 Oh and random observation - jzintv does not display the rightmost column of pixels for me. It actually sorta hides a bit of the card re-use but took me a while to figure out what I was doing wrong (I was counting pixels from the right at one point). Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted December 14, 2014 Share Posted December 14, 2014 Well, I did use this for reference because of the music on the title page... sound-of-music1.jpg I like my clouds better tho... Yes, your clouds are more natural. And that lady looks nothing like a goat! Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted December 14, 2014 Share Posted December 14, 2014 Oh and random observation - jzintv does not display the rightmost column of pixels for me. It actually sorta hides a bit of the card re-use but took me a while to figure out what I was doing wrong (I was counting pixels from the right at one point). That's not jzIntv: the STIC does not display the right-most column of pixels on each frame; jzIntv is just simulating this accurately. Quote Link to comment Share on other sites More sharing options...
+DZ-Jay Posted December 14, 2014 Share Posted December 14, 2014 DZ's suggestion, plus a couple of pixels adjusted on some other snow to hide some lines: ROM, or it didn't happen. Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 14, 2014 Author Share Posted December 14, 2014 That's not jzIntv: the STIC does not display the right-most column of pixels on each frame; jzIntv is just simulating this accurately. Well I'll be dipped. I'm sure to forget this in the near future, but thanks! This explains some rather terse mentions I've seen of 159x96 resolution. I thought someone made a highly-specific typo. 2 Quote Link to comment Share on other sites More sharing options...
freewheel Posted December 14, 2014 Author Share Posted December 14, 2014 ROM, or it didn't happen. Pointless sub-pixel release update. We'll call it a 0.0001 version: goat.rom 2 Quote Link to comment Share on other sites More sharing options...
intvnut Posted December 17, 2014 Share Posted December 17, 2014 (edited) Well I'll be dipped. I'm sure to forget this in the near future, but thanks! This explains some rather terse mentions I've seen of 159x96 resolution. I thought someone made a highly-specific typo. Yep. It's a rather interesting and obscure quirk of the STIC. But not one I imagined. I actually had to add code to the STIC emulation to mask out that column. It also factors into border collisions between MOBs and the border. Here's the actual code, including an #if 0'd bit from when I was figuring out the exact dynamics of the 160th column.... . /* ======================================================================== */ /* STIC_FIX_BORD -- Trim the display list and MOB image to 159 columns. */ /* ======================================================================== */ LOCAL void stic_fix_bord(stic_t *stic) { int i, j; uint_32 *const RESTRICT mpl_vsb = stic->mpl_vsb; uint_32 b_msk; int h_dly = stic->raw[0x30] & 7; #if 0 /* -------------------------------------------------------------------- */ /* Make sure column 159 holds nothing interesting, and has no bg bits */ /* beyond column 160 to cause false collisions. */ /* -------------------------------------------------------------------- */ n_msk = 0xFFFFFFF0 << (h_dly * 4); b_msk = 0xFFFFFFFE << (h_dly); bord = stic_color_mask[bord] & ~n_msk; for (i = 0; i < 12; i++) { for (j = 0; j < 8; j++) { uint_8 new_bmp = bt_bmp[19*8 + 20*8*i + j] & b_msk; bt_bmp[19*8 + 20*8*i + j] = new_bmp; } } #endif /* -------------------------------------------------------------------- */ /* We do the same for the MOBs, but we do this to column 167, because */ /* the MOB bitmap starts 8 pixels to the left of the backtab bitmap. */ /* -------------------------------------------------------------------- */ b_msk = 0xFE000000 << (h_dly); for (i = 0; i < 224; i++) { uint_32 new_vsb = mpl_vsb[i*6 + 5] & b_msk; mpl_vsb[i*6 + 5] = new_vsb; } /* -------------------------------------------------------------------- */ /* Trim the MOB collision bitmaps for left, right edges. */ /* -------------------------------------------------------------------- */ for (i = 0; i < 8; i++) { uint_32 le_msk, re_msk, msk; uint_32 x = (stic->raw[i + 0x00] & 0xFF) + h_dly; le_msk = x < 8 ? 0xFFFFFE00 << x : 0; re_msk = x > 150 ? 0x00007FFF >> (167 - x) : 0; msk = ~(le_msk | re_msk); for (j = 0; j < 16; j++) stic->mob_bmp[i][j] &= msk; } } . There's another bit further down in the file where I explicitly merge in the border color in column 160. Clipping the display to 159 columns was no accident. . /* ======================================================================== */ /* STIC_MERGE_PLANES -- Merge MOB and BACKTAB planes. */ /* ======================================================================== */ LOCAL void stic_merge_planes(stic_t *stic) { uint_32 *const RESTRICT image = stic->image; /*uint_32 *const RESTRICT bt_img = stic->bt_img;*/ uint_8 *const RESTRICT bt_bmp = stic->bt_bmp; uint_32 *const RESTRICT xbt_img = stic->xbt_img; uint_32 *const RESTRICT xbt_bmp = stic->xbt_bmp; uint_32 *const RESTRICT mpl_img = stic->mpl_img; uint_32 *const RESTRICT mpl_vsb = stic->mpl_vsb; uint_32 *const RESTRICT mpl_pri = stic->mpl_pri; int bt, ri, bti_idx, btb_idx, img_idx, bmp_idx, r, c, y, cc; int img_ofs; int v_dly, h_dly, top, lft; uint_32 bord = stic_color_mask[stic->raw[0x2C] & 0xF]; // ... a bunch of stuff snipped ... /* -------------------------------------------------------------------- */ /* Apply top and bottom borders. */ /* -------------------------------------------------------------------- */ top = (stic->raw[0x32] & 2 ? 32 : 16); /* 32 or 16 rows. */ memset(image, bord, top * 192 / 2); memset(image + 208*24, bord, 16 * 192 / 2); /* -------------------------------------------------------------------- */ /* Apply left and right borders. */ /* -------------------------------------------------------------------- */ lft = stic->raw[0x32] & 1; for (r = 16, ri = 16*24; r < 208; r++, ri += 24) { image[ri ] = bord; image[ri + 21] = bord; if (lft) image[ri + 1] = bord; } /* -------------------------------------------------------------------- */ /* Fill in colors in column 159. */ /* -------------------------------------------------------------------- */ for (r = 16 + v_dly, ri = r*24 + 20; r < 208; r++, ri += 24) image[ri] = (0xFFFFFFF0 & image[ri]) | (0xF & bord); } . Edited December 17, 2014 by intvnut 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.