|
Post by tbird on Jan 31, 2019 8:56:11 GMT -6
One suggestion is to do your shots so they have a "active" state so if they are active they can collide, be seen...etc. On impact they then become inactive....you get what I am saying, that way no continued shot.
|
|
|
Post by kennn on Jan 31, 2019 11:43:00 GMT -6
If n00b can also give his opinions, that will be very encouraging.
This is an important game in the history of RC BASIC.
|
|
|
Post by johnno56 on Jan 31, 2019 15:25:03 GMT -6
Ah, they bring back memories... After my CPC464 died, some years later, when emulators were more stable, I downloaded all the Amstrad games disc images... A clever use of colours and colour-cycling and multi-coloured sprites made Amstrad games popular. Compared with the colour palettes of other 8 bit machines, and the number of colours available, made most of the games visually appealing. Compared to them, my game is not... *sigh* I am handy with a graphics editor but not 'that' good... lol I only used 'full screen' to test for lag. Besides, running at normal sizes (320x200 and 640x200) on a 1920x1080 screen, tends to make them look 'small'. What puzzles me about 640x200 is that, on an Amstrad, if you placed a 200x200 square in the top left corner, it will look like a square on the left side of the screen from top to bottom. But the screen does not "look" like a 200 pixel height screen. It looks more like 400. Maybe Amstrad had a way of slightly 'stretching' the height of each pixel. I don't know. But if I converted the game to 640x200 it would look like you were watching one of those "letter box" wide screen movies. I am not sure that the rules meant for us to 'emulate' the way the machine does things but more on how it appears... I could be wrong... Do you want me to convert it to 640x200? Personally, I think that making the game in 320x200 then viewing it at full screen, will give the 'appearance' of 640x400 while maintaining a "legal" resolution. Actual Mode 2, 1 and 0 (640x200, 320x200 and 160x200) yet they all "look" the same - except for the squashed text of mode 0 - lol If you were to create the same screen resolutions using RC (or any other language), then all three images, would "look" different. Am I making any sense? Therefore, if I were to make the game at 640x200, it would not "look" normal. It would comply with the rules but would be "strange". Changing to 320x200, and viewing at full screen, would solve the "look" issue but would mean that the sprites would have to be reduced in size... My brain hurts again... I'm open to suggestions.... J
|
|
|
Post by johnno56 on Jan 31, 2019 16:54:34 GMT -6
Decided to go with the 320x200 at full screen. Preliminary tests show very little difference between it and the 640x400 at full screen. Hopefully I will have it done by days end. By the way. I now have the smallest enemy firing randomly at the player. Fine tuning needed to fire when aligned with the player...
|
|
|
Post by kennn on Jan 31, 2019 18:54:26 GMT -6
Decided to go with the 320x200 at full screen. Preliminary tests show very little difference between it and the 640x400 at full screen. Hopefully I will have it done by days end. By the way. I now have the smallest enemy firing randomly at the player. Fine tuning needed to fire when aligned with the player... 640/200 = 3.2 160/200 = 0.8 These two resolutions' aspect ratios are near. It is easier to handle the graphics than the above two resolutions. However, only 4 different colours can be used on the screen. 320/200 = 1.6 1920/1080 = 1.77 If participant chooses 640x200 or 160x200, this participant needs to make the sprites carefully. It is because, when this game is played in full screen, the original 640x200 game screen will be stretched vertically, or the original 160x200 game screen will be stretched horizontally. If choose 640x200 resolution, when play the game in full screen, 640x200 screen is stretched verticially, and therefore, all items will be taller in full screen. Therefore, when making the game sprites, make them shorter. When play the game in full screen, the sprites will be stretched to participant's expected heights. On the contrary, if choose 160x200 resolution, when making sprites, need to make the sprites thinner because 160x200 game screen will be stretched horizontally. Right?
|
|
|
Post by kennn on Jan 31, 2019 18:57:15 GMT -6
One suggestion is to do your shots so they have a "active" state so if they are active they can collide, be seen...etc. On impact they then become inactive....you get what I am saying, that way no continued shot. Hi, right.
|
|
|
Post by johnno56 on Jan 31, 2019 21:53:55 GMT -6
Oh no... That means I can ONLY hit one bad guy at time? Well there goes my 'edge'... lol
|
|
|
Post by kennn on Feb 1, 2019 2:02:51 GMT -6
Oh no... That means I can ONLY hit one bad guy at time? Well there goes my 'edge'... lol Only suggestion. The decision of the gameplay is still made by you.
|
|
|
Post by johnno56 on Feb 1, 2019 3:57:42 GMT -6
Nah... The concept of one bullet per bad guy (unless protected by armour or shielding) is still a valid point... Oh... Shields! Food for thought... I think I should concentrate on getting the game working properly before 'adding extras'... lol Oh... different weapons...
|
|
|
Post by johnno56 on Feb 1, 2019 5:00:07 GMT -6
Hmm... 4 colours... Remember the old game that Atari put out? Battlezone or Tankzone. Not sure which. Used vector graphics but only two colours. Black and green... Hmm...
|
|
|
Post by kennn on Feb 1, 2019 7:10:21 GMT -6
Hmm... 4 colours... Remember the old game that Atari put out? Battlezone or Tankzone. Not sure which. Used vector graphics but only two colours. Black and green... Hmm... I found a video on Youtube! www.youtube.com/watch?v=ymrYkbEbnEQ
|
|
|
Post by kennn on Feb 1, 2019 7:31:06 GMT -6
I only used 'full screen' to test for lag. Besides, running at normal sizes (320x200 and 640x200) on a 1920x1080 screen, tends to make them look 'small'. What puzzles me about 640x200 is that, on an Amstrad, if you placed a 200x200 square in the top left corner, it will look like a square on the left side of the screen from top to bottom. But the screen does not "look" like a 200 pixel height screen. It looks more like 400. Maybe Amstrad had a way of slightly 'stretching' the height of each pixel. I don't know. But if I converted the game to 640x200 it would look like you were watching one of those "letter box" wide screen movies. I am not sure that the rules meant for us to 'emulate' the way the machine does things but more on how it appears... I could be wrong... Do you want me to convert it to 640x200? Personally, I think that making the game in 320x200 then viewing it at full screen, will give the 'appearance' of 640x400 while maintaining a "legal" resolution. Actual Mode 2, 1 and 0 (640x200, 320x200 and 160x200) yet they all "look" the same - except for the squashed text of mode 0 - lol If you were to create the same screen resolutions using RC (or any other language), then all three images, would "look" different. Am I making any sense? Therefore, if I were to make the game at 640x200, it would not "look" normal. It would comply with the rules but would be "strange". Changing to 320x200, and viewing at full screen, would solve the "look" issue but would mean that the sprites would have to be reduced in size... My brain hurts again... You can read the discussion between them. Maybe you will understand more about rules, resolutions or palette. syntaxbomb.com/index.php/topic,5206.msg22544.html#msg22544 (add www.)
|
|
|
Post by johnno56 on Feb 1, 2019 7:55:06 GMT -6
Yep. Found that little sight earlier. I think I will stick to 320x200. At least I can use 4 colours. 160x200 will allow 16 colours but the display was stretched too wide... lol Not too sure about the green and black colouring. A 2 colour looking game would need some wicked gameplay to make it work and I'm not sure if I have the skill set to do that.... It's almost 1am and I have to be up at 5:30am... Might be a good idea to shutdown and get some sleep...
J
|
|
|
Post by tbird on Feb 1, 2019 9:12:51 GMT -6
Another suggestion, is perform a bounding box collision then do pixel detection in the same routine, that way you wouldn't be running the getpixel all the time, but only in the instance that a collision "might" occur.
|
|
|
Post by kennn on Feb 1, 2019 10:51:48 GMT -6
Yep. Found that little sight earlier. I think I will stick to 320x200. At least I can use 4 colours. 160x200 will allow 16 colours but the display was stretched too wide... lol Not too sure about the green and black colouring. A 2 colour looking game would need some wicked gameplay to make it work and I'm not sure if I have the skill set to do that.... It's almost 1am and I have to be up at 5:30am... Might be a good idea to shutdown and get some sleep... J I think that 4 colors can be changed in entry. For example, level 1(use red, green, black, white), level 2(use pink, purple, yellow, blue), etc.
|
|