 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Seeking Games Programmers
Page 1 of 9   |
|||||
| Author | Message | ||||
Geoffg Guru  Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Is there anyone out there who is a "game programmer"? I am planning an upgrade to the Colour Maximite using the MZ processor and a modified version of Peter Mather's port of MMBasic to the MZ (ie, the Micromite eXtreme). The idea is to retain the factors that made the Maximite so popular (VGA, colour graphics, etc) and upgrade the processor and MMBasic to produce a BASIC computer that is a super version of the TRS-80, Apple II, etc. Something that would be a fun computer to play around with and good for general computing, games, etc without the complexities of Windows or Linux. The original Maximite has "sprites" which were supposed to be the basic elements for constructing games graphics but they were never very successful. For the new version I would like to implement something more useful and hopefully based on some sort of standard approach that a games programmer would understand. So, what I am looking for is some standard for gaming primitives that I could implement. I am not a games programmer so help from anyone expert in this area would be gratefully received. Perhaps the answer might be to fix whatever was broken in the original sprite implementation (for reference, below is the definition of SPRITES). 2018-01-18_110653_Maximite_Sprites.pdf Looking forward to some input, Thanks, Geoff Geoff Graham - http://geoffg.net |
||||
OA47 Guru Joined: 11/04/2012 Location: AustraliaPosts: 899 |
Looking forward to the end product.  OA47 |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Nick? Microblocks. Build with logic. |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Geoff, I will gladly put myself forward as I think you know I have made some headway in this already on the MMX. Wanted to release the game that you know about very soon as there are many people from 8-bit Guy contacting me regarding MMX144. I wanted to release it before one of 'them' spent time doing it. (Email me your thoughts about this) I also have an addictive playable version of 'Wormy' (Snake) which I use in my demo-s but need to convert to run on MMX as resolution is all different. Invaders was my next 'conversion' to colour . . . . WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
Azure Guru Joined: 09/11/2017 Location: AustraliaPosts: 446 |
It's been a long time since I worked in the arcade video game industry, but here is an attempt to revive some prehistoric brain cells: Sprites in classic arcade games had some other features available. Just for some background info in case it is of any use. This was generally based on an 8 bit microprocessor running at 4MHz. The sprite object (which was hardware based, on early arcade hardware to about 8 objects) does not contain the graphic image itself. It contains a lookup into a object file, like a character in a font, but is usually equivalent to 2x2 font characters mapped to create one object. So an 8x8 sized font character makes a 16x16 object. That way a static object (residing in the font) can come alive by overlaying a sprite object in the same position while the character map changes and the sprite then moves. This makes it possible to make it look like there are many more sprites than the hardware actually has. The object has bits to flip in either/or X/Y and on some games a limited scale factor. The sprite object colours in classic arcade hardware was an index into a colour palette, not the colour itself. The colour was able to be changed by changing the colour index table colours. In classis games there was a limited size to the number of colour sets (it was in a small high speed PROM). This means the program animated moving objects (over the background and tile array) using sprites. The use of index values rather than embedded values (image and colour) made animating the moving characters and applying effects (by the use of colour) very efficient. For the classic games there was a lot of trickery used to make the best of the hardware. As an example and another 'sprite' type in the classic games, if you remember shoot'em style games that were played top to bottom the monitor was always in portrait mode and if played left to right the monitor was always in landscape mode. This was done as the missiles and bullets were special (limited) fixed image sprites that were drawn aligned to the horizontal trace line. My feeling is the 'sprites' on the micromite is the image drawing part and the classic game sprite harware (the object information) could be done with subroutines or functions. |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Could CFunctions be ported to the Maximite. Then lacking functions could be added. A high speed direct access to the graphic planes can enable all sorts of things that are not thought of right now. Microblocks. Build with logic. |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 1985 |
I used to knock around with a guy who went on to form his own very successful games company and (according to LinkedIn) is still doing it today. Although not related to the question of "how to" with sprites he told me a great trick was to have a hit mask for sprites that was smaller than the visual image. This encouraged players to squeeze through gaps which massively increases play-ability and avoids the "that was nowhere near me!" syndrome - which has the opposite effect. The hit mask could either be a facet of the sprite itself or another invisible sprite which shadowed the first and generated the boundary events. You now have the sum total of my input on games programming... it was in the 80's for gawd's sake  |
||||
darthmite Senior Member  Joined: 20/11/2011 Location: FrancePosts: 240 |
Hi Geoff Just take the lib i writed for the stm32mite it is especialy effective with sprites , screen buffer , blit , clipping and so on. I have see that the PIC32MZ DA is the chip to use for what you want do. 640KB of SRAM , 32Mb of SDRAM and 2MB Flash , more than the stm32f7 i used for mmbasic on the stmmite For the VGA output just use the pic32mz-da pins that are coming out the internal graphic controller (i have do it on stm32 with a simple R2R DAC) it work well. But it will be good to choose if we want VGA or LCD (to be portable). Here the schematic : 2018-01-18_194707_st429dac.PDF Link to one off my test video with this DAC : test vga stm32f429 Now a video from Uwe Becker from what was possible on mmbasic with stm32f7 concerning game map and sprites : https://www.youtube.com/watch?v=5g3-ztufoNM It's just sad that i no more have time to play with that and Uwe Becker disapear 2 year ago (i dont know where) ... So , i hope my lib can help to do it on the new pic32mz da cheers. Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 278 |
Hi Geoff. I would suggest a look at some old BASIC programming manuals to give you some idea's of how it used to be done. I would recommend the old TI99/4a and AMOS BASIC for the Amiga. AMOS BASIC had some great features for sprite handling, animation and collision detection. It also used BOBS (Blitter Objects)Link Also this about Sprites link Dave. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Hi Fabrice, good to hear from you. I will check out your code. 176 pins in a LQFP package... Gulp. Geoff Graham - http://geoffg.net |
||||
| cosmic frog Senior Member Joined: 09/02/2012 Location: United KingdomPosts: 278 |
Just looking at the sprite command in the MaxiMite manual again, I think one of the things that let it down the most was the collision detection, you knew you had collided with something but didn't know what! The sprite handing and syntax could be a lot more simple with something like this - SPRITE(spr,image,x,y,col) here you have almost everything in one command. Spr=sprite number Image = the graphic used to make the sprite X and y = screen coordinates Col = collision detection (returns the sprite number you've bumped into) Dave. |
||||
| Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3165 |
Sounds good Dave. The only issue I can think of is that you could bump into two other sprites simultaneously as well as walls. Collision reporting was one area I felt was lacking, the other was being restricted to 16x16 bit sprites. Geoff Geoff Graham - http://geoffg.net |
||||
| WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
If not already mentioned, then 'Layers' are another thing to consider. 99% of requirements for SPRITEs in games are as follows: 1> Define (i.e. LOAD) a multi-colour sprite (give it a sprite reference number, and pixel-colour info with a method to represent 'transparent'). Allow for x pixels wide, and y pixels high (i.e. not necessarily square) 2> DRAW a sprite (by above sprite reference number, layer number, and location on screen) - Allow for edge of screen drawing (i.e. part of the sprite is off the screen). Ideally each 'object' you draw has its own unique ref number too allowing SPRITE x to be drawn in multiple positions and/or layers. 3> REMOVE a sprite from screen (ideally by unique reference number in Point 2 above) 4> Unload a sprite from memory (i.e. to recover memory) 5> Collision detection - only on same layer. Ideally as pointed out above in another post, there is a 'Collision Mask' definition allowing things such as a 'ball' to be detected at the 'ball edge' rather than the 'sprite block' edge) The layer concept deals with what appears in the foreground, and what is in the background (i.e. what passes in front of what) Hope this all makes sense  WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
MZ could support 2, possibly three layers for VGA but only a single layer for 800*480 TFT and even there the framebuffer is the SSD1963 controller itself The DA route could do it but that requires memory external to the processor. i.e. much more complex hardware I recommend sprites are loaded from .PNG files as this is the standard for CSS (and I've already got this working on the MZ) |
||||
| darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240 |
Hi matherp If the pic32mz da is like the stm32 then the internal graphics controller take care on the LCD bus (timing , etc ... ) no more need to use SSD1963 or any other external controller , you just need a LCD with no integrated controller and a ... datasheet  And (the thing i dont know) if the CPU use the internal 32Mb sdram for screen buffer you will then have the possibility to use alot more layers (like stm32 with external sdram). So the internal SRAM will just be needed for your variables ... I mean this chip : pic32 @Geoff : 176 lqfp is doable easily (with no shaky hands) , Dave from eevblog show you how eevblog smd soldering Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8578 |
Yes you are correct - my bad. I'd assumed the 32Mb was external like the STM but it is internal in some of the DAA chips and not others Best choice looks to be PIC32MZ2025DAG176 but there seems to be very little demo/example software and certainly not VGA or HDMI |
||||
| hitsware Guru Joined: 23/11/2012 Location: United StatesPosts: 535 |
> (VGA, colour graphics, etc) Are you sure about VGA ? It seems that now HDMI monitors are more prevalent. AND ! Don't forget about sound ! Something like this would be great ! (Maybe you want only single chip though?) |
||||
| darthmite Senior Member Joined: 20/11/2011 Location: FrancePosts: 240 |
take care mat , PIC32MZ2025DAG176 have 256kb SRAM but , PIC32MZ2064DAG176 got 640kb. The internal SRAM is ultra fast , best is to get the chip with more And it cost only $2 more than the 256kb version I go look now on my microchip account if i can get some ... If they have it in stock i will then have to look for made a PCB ... that s**ks , china are slow builder ... Cheers Theory is when we know everything but nothing work ... Practice is when everything work but no one know why ;) |
||||
panky Guru Joined: 02/10/2012 Location: AustraliaPosts: 1094 |
From my experience as a "grandpa", Mum and Dad get a new 55" plus wide screen for the lounge and the kids get the older (but still pretty new) flat screen for gaming. Very few 4:3 style tv's around now - almost all are 16:9 or similar wide screen so I think that HDMI would be essential and as already stated, includes audio option. How feasible is HDMI in firmware on an MZ? panky. PS. Very exited about this project - many retro games out there that could interest a whole new generation as well as the "older" fo9lks like me who just can't get exited about Minecraft and so on. ... almost all of the Maximites, the MicromMites, the MM Extremes, the ArmMites, the PicoMite and loving it! |
||||
| MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Hope to not start a new 'war' but in 2013 i made a suggestion for adding a joystick function and define some default pins. This would then result in people using the joystick command/function instead of implementing there own and by that making it more difficult to share their code. I used these pins: [code] Software pin Joystick signal Pin D7 Up Pin D6 Down Pin D11 Left Pin D12 Right Pin D10 Fire Button Connector J2 pin 1 Pot X J3 pin 1 Pot Y A second joystick: Software pin Joystick signal Pin D2 Up Pin D1 Down Pin D3 Left Pin D0 Right Pin D4 Fire Button Pin A0 Pot X Pin A1 Pot Y [/code] If joystick feature can be added as a MMBasic function it would be nice to choose pins that are on the same PIC32 port. This will make implementing it much easier. If functionality for games are to be added or improved i think having two joysticks would be great. It allows for two player games, more complicated control games and beyond games it would be a great way to control robotics,servos,steppermotors etc. Microblocks. Build with logic. |
||||
| Page 1 of 9 |
|||||
 Print this page |
