Although we were born in the 8 bit era, our first computer was an Amiga 500. It was a glorious 16-bit machine, and it featured stunning graphics and sound, making it well suited for gaming. Electronics has changed a\nlot since the 90s, and now there are plenty of small microcontrollers that\nallow you to create very spectacular things.<\/p>\n\n\n\n We always loved platform\ngames, and now with few bucks one can buy a Raspberry Zero, install Linux, and\nprogram a colorful platformer \u201cquite easily\u201d. <\/p>\n\n\n\n That’s not a job for us,\nit’s like using a nuke to kill a mosquito!<\/p>\n\n\n\n We want to use microcontrollers, with limited memory, not powerful system on a chip with built-in GPU! In other words: we want some challenge!<\/p>\n\n\n\n Speaking about video capabilities, some people managed to squeeze every drop out of an AVR microcontroller with some projects (like the Uzebox project or Craft by lft). However, to achieve this, AVR microcontrollers force you to write in assembly, and even if there are some examples of very nice games, you\u2019ll face some heavy constraints, that won\u2019t allow to get a 16-bit style game. <\/p>\n\n\n\n Instead, we would like to use\nsome more balanced microcontroller\/board, that allowed us to code entirely in\nC. <\/p>\n\n\n\n Not as powerful as an Arduino\nDue but not as limited as an Arduino Uno. Interestingly enough, \u201cDue\u201d means 2,\nand \u201cUno\u201d means 1. And just like Microsoft taught us how to count (1, 2, 3, 95,\n98, ME, 2000, XP, Vista, 7, 8, 10), Arduino cannot be any different! We will\nuse Arduino Zero as intermediate between 1 and 2! <\/p>\n\n\n\n Yes, 1 < 0 < 2,\naccording to Arduino \ud83d\ude42<\/p>\n\n\n\n In particular, what we are\ninterested in, is not the board itself. Instead, we are considering its processor\nseries. The Arduino Zero mounts an ATSAMD21 series microcontroller, with a\n48MHz Cortex M0+, 256kB of flash, and 32kB of RAM.<\/p>\n\n\n\n While a 48MHz Cortex M0+ could largely outperform an old 7 MHz MC68000, the Amiga 500 had 512kB of RAM, hardware sprites, built in dual playfield, the Blitter (a DMA based block image transfer engine, with built in pixel exact collision detection system and transparency) and the Copper (a raster based coprocessor, which allowed to perform register operations based on the raster position, to create a lot of very nice effects). These sounds like rather hard to achieve goals. For instance a 160×128 pixel screen takes 40kB for frame buffer at 16 bit, but we only have 32kB of RAM! And we also want dual playfield parallax scrolling, and a lot of other stuffs, at 25\/40 fps at least! <\/p>\n\n\n\n But we are next-hack here,\naren’t we?<\/p>\n\n\n\n We will use some tricks and embedded ATSAMD21 features! It has the same specs of the Arduino Zero, but it is much smaller, not considering it is also cheaper than an original Arduino Zero (yes, you can buy counterfeit Arduino Zero for 10$ in AliExpress\u2026 but we like to stick to original one) . This will allow us to make a small hand held console. You can adapt this project with almost no effort to Arduino Zero. You\u2019ll just have a bulky result though.<\/p>\n\n\n\n We also created a small test board, which implements a poor man’s hand held console. Details are shown below!<\/p>\n\n\n\n We won’t be using the Arduino framework though. It\u2019s not well suited when it comes to optimization and hardware control. (And let’s not talk about the IDE!)<\/p>\n\n\n\n In this series, we will see\nhow we arrived to the final version of the current game, and we will describe\nall the optimization and the criteria we used. The game itself is not finished,\nand it lacks sound, levels, etc. However this can be still used as a starting\npoint for many types of game!<\/p>\n\n\n\n Furthermore, there is room for\na lot of optimization, even without assembly!<\/p>\n\n\n\n So, let’s start our journey!<\/p>\n\n\n\n There are essentially two\nchallenges on this project. Timing and memory (both RAM and storage).<\/p>\n\n\n\n Let’s consider the memory first.<\/p>\n\n\n\n First of all, instead of storing a huge picture of the level, we will use tiles. In fact, if you closely analyze most of the platform games, you’ll notice that these are made of a small quantity of graphics element (tiles) repeated many times.<\/p>\n\n\n\n The world\/level appears as\nvaried because of the different tile combinations. This saves a lot of storage\nmemory, but it does not solve the problem of the huge frame buffer.<\/p>\n\n\n\n The second trick we will be\nusing is that our uC has both a quite amount of processing power and it has DMA\ntoo! Therefore, instead of storing all the frame data in RAM (why should we,\nanyway?), we will be create the scene from scratch each frame. In particular we\nwill still use buffers, but just large enough to contain a single 16-pixel tall\nhorizontal block of graphics data.<\/p>\n\n\n\n When an engineer has to\nmake something, the first step is to check if something is feasible. Of course,\nwe did this check at the beginning! <\/p>\n\n\n\n Well, we want at least 25\nfps on a 160×128 pixel display. This means 512000 pixels\/s. Since our\nmicrocontroller runs at 48 MHz, we have at least 93 clock cycles per pixel. This\namount of cycles reduces to 58 if we want to go at 40 fps.<\/p>\n\n\n\n Actually, our\nmicrocontroller can handle up to 2 pixels per time, because each pixel is 16\nbit, but the ATSAMD21 has a 32 bit internal bus, so the figures could be\nbetter!<\/p>\n\n\n\n 93 clock cycles per pixel\nsuggests us that actually the task is quite feasible! In fact, we might also\nconclude that the CPU alone might be enough to perform all the drawing tasks,\nwithout DMA. This is probably true, especially with assembly. However, the code\nwould be extremely difficult to handle. And in C it should be very optimized! A\nCortex M0+, in fact, is not as C-friendly as a Cortex M3, and it lacks many\ninstructions (even load\/store with post\/pre increment\/decrement are missing!),\nwhich have to be implemented with two or more simpler ones.<\/p>\n\n\n\n Let\u2019s check what we need to do, to draw the two playfields (assuming we already know the x and y coordinates, etc).<\/p>\n\n\n\n Furthermore, these\noperations must be performed for each sprite that might appear in the buffer:<\/p>\n\n\n\n Not only all these\noperations are not implemented as a single ASM instruction, but also, each ASM instruction\ntakes two cycles when accessing RAM\/Flash memory.<\/p>\n\n\n\n Moreover, we are also missing game logic (which, luckily takes a negligible amount of time as they are calculated once per frame), collision detection, buffer handling, and the instructions needed to send the data via SPI.<\/p>\n\n\n\n For instance, here is what\nwe would have to do in pseudo code (assuming no scrolling and a fixed color\nbackground playfield for now!) just for the foreground.<\/p>\n\n\n\n Let cameraY and cameraX be\nthe coordinates of the top left corner of the display in the game world.<\/p>\n\n\n\n Let xTilepos and yTilepos be the position of the current tile in the map.<\/p>\n\n\n\n The number of instructions for 2560 pixels (160 x 16) is about 16k, i.e. 6 per pixel. Actually one could draw two pixels at once. This halves the effective number of instructions per pixel, so the number of high-level instructions per pixel is about 3. However, some of these high-level instructions will either be split in two or more assembly instructions, or they will require at least two cycles to complete, because they access to the memory. We are also not considering CPU pipeline flush due to jump, and wait states for the flash memory. Yes, we might be far from the 58-93 available cycles, but we must count the background playfield and the sprites.<\/p>\n\n\n\n Although this shows that it\nis feasible even with only the CPU, we will see that DMA is much faster. This\nleaves more room for more on-screen sprites or better graphics effects (we\ncould implement alpha blending for instance).<\/p>\n\n\n\n We will see that the number\nof C instructions required to set-up the DMA for each tile is less than 100,\ni.e., we need less than 0.5 instructions per pixel! Of course, DMA still has to\nperform the same number of memory transfer, but the address increment and the\ntransfer is done without any CPU intervention, which is therefore free to do\nsomething else (e.g. computing and drawing sprites).<\/p>\n\n\n\n Using the SysTick timer, we found that the time required to setup the DMA for an entire block, and then waiting for the DMA to finish, is about 12k clock cycles. Please note: clock Cycles! Not high level instructions! The number of cycles is rather high for only 2560 pixels, i.e. 1280 32-bit words. In fact we get about 10 cycles per 32-bit word. However, one should take into account the time required to set up the DMA, and also the time required by the DMA to load from RAM the transfer descriptors (which essentially contain the pointers and number of bytes to transfer). Furthermore, there is always some sort of memory bus arbitration (to avoid starving the CPU), and the Flash memory requires at least one wait state. <\/p>\n\n\n\n The other bottleneck is the\nSPI. Is 12 MHz fast enough for 25 fps ? The answer is yes: 12 MHz corresponds\nto about 36 frames per second. If we use 24 MHz, then the limit would be two\ntimes as large!<\/p>\n\n\n\n By the way, the datasheets\nof the display and the microcontroller show a maximum SPI speed of 15 and 12\nMHz, respectively. We actually tested that these can be pushed to 24 MHz with\nno problem, at least in the \u201cdirection\u201d (the microcontroller writes to the\ndisplay) we want.<\/p>\n\n\n\n We will use a popular 1.8\ninch SPI display. We verified that both ILI9163 and ST7735 work fine (at least\nat 12 MHz. The ST7735 is confirmed to work at up to 24 MHz). If you want to use\nthe same display of the tutorial “how to play a video on Arduino Uno”,\nwe suggest to modify it, if later you want to add SD support. As we said we will use tiles. Each level will consists of tiles repeated according to a table, which we will call \u201cgameMap\u201d. However fewer tiles per screen would be required, increasing speed (see later) and reducing the map size (i.e. number of rows and columns in the table) for each level. Our screen is 160×128. In\nother words, we need 10×8 tiles per screen, i.e. 80 entries in our table. A\nhuge level, with 10×10 screens (or 100×1 screens), will require only 8000\nentries (16 kB if we use 16 bit per entry. We will show you later why we are\ngoing to use 16 bit per entry).<\/p>\n\n\n\n Let’s compare this with the\namount of memory we would likely use if we stored a big picture of the entire\nscreen: 40k*100= 4MB! That’s insane!<\/p>\n\n\n\n Let’s talk about the\ndrawing system!<\/p>\n\n\n\n Each frame will need to contain (in order of drawing):<\/p>\n\n\n\n In particular, we will perform sequentially these operations: <\/p>\n\n\n\n Background and completely opaque tiles will be drawn by DMA. A completely opaque tile is a tile in which there are no transparent pixels. <\/p>\n\n\n\n Partially transparent tiles, sprites and overlay cannot be efficiently drawn by DMA. In fact, the DMA system of the ATSAMD21 merely copies the data, and unlike Amiga’s Blitter, it does not check for transparency (which is determined by the color value). Finally, data is sent to the display using DMA. <\/p>\n\n\n\n As you might see, if we\nperformed these operation in sequence on the same buffer, we would waste a lot\nof time. In fact, when the DMA is working, the CPU would not be doing anything,\nexcept for waiting that DMA has finished doing its job! This is not a good way\nto implement a graphic engine! Furthermore, when the DMA sends data to the SPI\nunit, it does not exploit its full bandwidth. In fact, even when the SPI works\nat 24 MHz, data is sent only with a frequency of 3 MHz, whch is a rather low\nfigure. In other words, the DMA is under used: the DMA could perform other\ntasks without losing too much in terms of performance.<\/p>\n\n\n\n That\u2019s why we implement a\npipeline, which is an extension of the double buffering (actually we use three\nbuffers!). Of course, at the end the operations are always performed in\nsequence. But at the same time the CPU and DMA perform different tasks, without\ninterfering (too much) each other. <\/p>\n\n\n\n We use in fact three\nbuffers, we will call block. <\/p>\n\n\n\n At the same time:<\/p>\n\n\n\n The ATSAMD21 DMA system\ncannot be compared to a blitter, but it still has some useful features. Thanks\nto the DMA, we can have a very high refresh rate, despite the presence of a\ndual playfield.<\/p>\n\n\n\n The DMA transfer\nconfiguration is stored in RAM, in \u201cDMA descriptors\u201d, which tell the DMA how\nand from where to where it should perform the current transfer. These\ndescriptors can be linked together: if the link is present (i.e. no null\npointer), the DMA will automatically fetch a new descriptor, once the transfer\nis complete. By using many descriptors, the DMA can perform \u201ccomplex transfers\u201d,\nwhich is useful when, for instance, the source buffer is a sequence of non\ncontiguous segments of contiguous bytes. The fetch and write back of the\ndescriptors, however, takes time, as it must save\/load 16 descriptor bytes from\nthe RAM.<\/p>\n\n\n\n The DMA can handle different data widths: bytes, half-words (16 bits) and words (32 bits). The datasheet calls this width as \u201cbeat size\u201d. For the SPI, we are forced to use byte transfers (even if the current REVD datasheet states that ATSAMD21’s SERCOMs have FIFOs – which Microchip claims they accept also 32-bit data -, it seems that actually it has no FIFO. The REVD datasheet also refers to a SERCOM CTRLC register, which is then missing both on the header files, and on the register description section. Luckily, unlike AVR, ATSAMD21 has at least a buffered transmit data register, so there won’t be transfer gap during send!). To draw the tiles we surely use 32 bits. This allows to copy two pixels per beat. The ATSAMD21\u2019s DMA also permits to increase the source or destination address each beat, by a fixed number of beat sizes. <\/p>\n\n\n\n These two aspects are very\nimportant, and they will determine how we draw the tiles.<\/p>\n\n\n\n First of all, if we drew only one pixel per beat (16 bit), we would halve the bandwidth of our system. We cannot renounce to the full bandwidth! <\/p>\n\n\n\n However, if we draw two\npixels per beat, the playfield could be only scrolled by an even number of\npixels, and this would not appear as a fluid motion. To overcome this, we could\nuse a buffer which is two pixels or more larger. When we send the data to the\ndisplay, we would use the correct offset (0 or 1 pixel) depending if we need to\nmove the \u201ccamera\u201d of an even or odd number of pixels. <\/p>\n\n\n\n However, for sake of simplicity we will reserve room for 11 entire tiles (160 + 16 pixel) instead of only 160+2 pixels. This has one big advantage: we will not need to calculate and update the destination address of each DMA descriptor (this would require several instructions, which might add too much overhead per tile). Of course, we will only draw the minimum number of pixels, i.e. at most 162. Yes, at the end this will waste some memory (about 1500 bytes, considering three buffers), for sake of speed and simplicity. Further optimization can be still performed.<\/p>\n\n\n\n In the animated GIF above,\nyou see all the 16 line buffers (without descriptors) of a block. On the right\nthere is what will actually appear on the display. The GIF shows the first 32\nframes, when you move rightward by 1 pixel each frame. The black portion of the\nbuffer is the part that it is not updated, and its content is just leftover\nfrom previous operations. When the screen is scrolled by an odd amount of\nframes, a 162-pixel wide is drawn on the buffer. However, of these, the first\nand the last column (which are highlighted in the animation) are discarded.\nWhen the scroll amount is a multiple of 16 pixels, the drawing operations on\nthe buffer start back at the first column (x = 0).<\/p>\n\n\n\n What about vertical\nscrolling?<\/p>\n\n\n\n This must be dealt after we\nshow you how tiles are stored in the flash memory.<\/p>\n\n\n\n A na\u00efve way (which would be\nOK if you used CPU-only drawing) to store tiles in the flash, is like a\nsequence of pixel colors. The first pixel of the first row, the second, etc\u2026\nuntil the 16th<\/sup>. Then you store the first pixel of the second row,\nthe second, and so on.<\/p>\n\n\n\n Why is this na\u00efve? Because\nin this way DMA could draw only 16 pixels for each DMA descriptor! Therefore\nyou would need 16 descriptors, which would require each one to make 4+4 memory\naccesses (that is to transfer 32 bytes \u2013 8 memory read + 8 memory write, the\nDMA has to perform other 4 reads + 4 writes). This is rather inefficient! <\/p>\n\n\n\n In fact, for each\ndescriptor, the DMA can increment only by a fixed amount of words the source\naddress and destination address. After the first row of the tile has been\ncopied to the buffer, the destination address should be incremented not by 1\nword, but by an amount so that it points to the next buffer row. This is not\npossible, because each transfer descriptor only specifies the beat-transfer\nincrement, which cannot be changed.<\/p>\n\n\n\n A much more smart way is to send the first two pixels of each row of the tile, in sequence, that is, pixel 0 and 1 of row 0, pixels 0 and 1 of row 1, etc, until pixels 0 and 1 of row 15. Then we send pixel 2 and 3 of row 0, and so on.<\/p>\n\n\n\n In the figure above, each\nnumber indicates the order on which the 16-bit pixel is saved on the tile\narray.<\/p>\n\n\n\n This can be done using one\ndescriptor, but we need two things:<\/p>\n\n\n\n The first is very simple to achieve: it\u2019s just a matter of reordering the data, it can be done when exporting the graphics to a c file (see previous picture).<\/p>\n\n\n\n The second one can be achieved because the DMA allows to increase the destination address, after each beat, of 512 bytes. This has two consequences.<\/p>\n\n\n\n The unused space, however,\ncan be still used, for examples, for the descriptors.<\/p>\n\n\n\n In fact each descriptor is\n16 bytes large. We need at least 10 * 8 (actually we need 11 * 8!) descriptors\nfor the tiles, and 16 descriptors for the SPI.<\/p>\n\n\n\n Here\u2019s why larger tiles\nwould lead to faster speed. In fact, if we used, for instance, a 32 x 32 tile,\nwe would need less descriptors per screen (320 instead of 640). This would\nreduce overhead. <\/p>\n\n\n\n The block buffer, the\ndescriptors and other data are stored in a structure type we called displayBlock_t.<\/p>\n\n\n\n A displayBlock is an array of 16 displayLineData_t. The displayLine data contains 176 pixels, plus 80 words. In these 80 words we store display descriptors, or other useful display data (using a union).<\/p>\n\n\n\n Since there are 16 lines,\neach tile in position X uses the first 8 DMA descriptors (0 to 7) of lines X.\nSince we have at most 11 tiles (hence the 176 pixel wide display line), the\ntiles only uses the DMA descriptors of the first 11 data lines. Descriptors 8-9\nof all the lines, and descriptors 0 to 9 of lines 11-15 are free.<\/p>\n\n\n\n Of these, descriptors 8 and\n9 of lines 0..7 will be used for the SPI. <\/p>\n\n\n\n The descriptors 0..9 of\nlines 11-15 (up to 50 descriptors, even though we will use only 48 of them)\nwill be used for the background playfield.<\/p>\n\n\n\n The picture below shows its organization.<\/p>\n\n\n\n The background playfield is treated differently. First, we must renounce to the two-pixel alignment, if we want smooth scrolling. This is because the foreground and background scrolls at different speeds. Therefore beats will be half-word large. Even if this has some drawback in terms of speed, this allows an easier integration. Since there is quite a small number of descriptors left, we can\u2019t use small tiles. Furthermore, to simplify everything and to quickly add parallax, we will use long \u201cslices”.<\/p>\n\n\n\n Background is actually\ndrawn only if there is at least one partially transparent pixel. This means\nthat if there is just a single transparent tile, the background will be drawn.\nThis is of course a waste of bandwidth, but it simplifies everything.<\/p>\n\n\n\n If we compare the\nbackground to foreground playfield:<\/p>\n\n\n\n As we said, we have on each\nblock, up to 11 tiles (10 full tiles, or 9 full tiles and 2 partial tiles). Each\nof these tiles is drawn by the DMA only if it is not marked as transparent.\nInstead, if they are not completely opaque, they are added to a list, which\nwill be analyzed later, when sprites are drawn. \n<\/p>\n\n\n\n The descriptors of the\nbackground playlist (which are always calculated) and those of the foreground\nplayfield form a very long linked list. The first part draws the background\nplayfield. The second part draws the tiles, over the background. The length of\nthe latter part might be variable, as the DMA descriptors of partially\ntransparent tiles are excluded from the list. If a block contains only opaque\ntiles, then the DMA is set up so that it starts directly from the first\ndescriptor of the first tile.<\/p>\n\n\n\n Transparent tiles and\nsprites are treated almost at the same way. The pixel of the tile\/sprite is\nanalyzed. If it is black, then it is transparent, therefore the background tile\nis not changed. Instead, if it is not black, the background pixel is replaced\nwith that one of the sprite\/tile.<\/p>\n\n\n\n When dealing with\nhorizontal scrolling, we draw up to 11 tiles, even if, when drawing 11 tiles,\nthe first and the last will be only drawn partially. This partial drawing is possible\nbecause each descriptor draws two columns of a tile, therefore we can easily\nset where to start and stop our linked list.<\/p>\n\n\n\n Instead, when dealing with vertical scrolling, we should compute both the destination register and the transfer count. This should set multiple times per frame. To avoid this hassle, we will simply draw up to 9 complete blocks per frame (just 8 when the scroll is a multiple of 16). <\/p>\n\n\n\n As we said, uChip is the\nheart. What about the other things?<\/p>\n\n\n\n Here is the schematics! There are some aspects about it that are worthy of discussion.<\/p>\n\n\n\n To optimize I\/O usage, we\nuse a small trick. There will be 4 sensing lines, L1-L4, and one common wire LC.\nThe common wire will be alternatively set to 1 and 0. The sensing lines will be\nalternatively pulled low or high, respectively, using the internal pull-up\/down\nresistors. Two keys are connected between each key line and the common line. In\nseries to these two keys, a diode is inserted. Each of these diode has the\nopposite polarity, so that only one key can be effectively \u201csensed\u201d each time.<\/p>\n\n\n\n Since there is no built in\nkeyboard controller (and since no embedded keyboard controller use this\npeculiar method), the eight keys are quickly sensed at the beginning of each\nframe. Since the inputs must be both pulled up and down, we cannot use (and we don\u2019t\neven want to) external resistors, so we must use the integrated resistors,\nwhich might be quite high valued (60 kOhm). This means that, when the common\nline changes state, and the sensing lines change their pull up\/down state, one\nshould insert some delay, to allow the integrated pull up\/down resistor\ncharging the pin and track parasitic capacitance to the desired level. This drastically increases the scanning speed and no delays\/nop are requested.<\/p>\n\n\n\n We connected the SD and the\ndisplay so that they can communicate each other without the data actually going\nto the ATSAMD21. This might be useful if you want to play a video. <\/p>\n\n\n\n The resistors that connects\nMISO and MOSI should be low valued. In fact if it is too high, the SPI will not\nwork, as the signal will be too much degraded.<\/p>\n\n\n\n One of the biggest issue is\nthe RAM usage. The three blocks take 8 kB each, leaving only 8 kB for stack,\nand the other variables. As for now, we have only 1.3 kB of free RAM + 4 kB of\nStack (4 kB of stack is very large, we might reduce it). <\/p>\n\n\n\n However, we could consider 8-pixel\ntall blocks, and not 16. This would increase the overhead for the DMA\ndescriptors, but it would cut almost by half the memory usage for the block buffer\n(note that the number of descriptors would not change, if we still used 16×16-pixel\ntiles, therefore we would need to change the block organization). This could\nfree about 7.5kB of RAM, which could be very useful, to easily implement some\nfeatures, like variable map with secrets, or add audio (though Audio could be\nstill easily added even with as low as 1kB of RAM).<\/p>\n\n\n\n Another issue is the\nsprite, but this modification is much easier, and it only involves the function\ncreateNextFrameScene(). In fact, we create a huge array in RAM with the state\nof all the sprites. For each sprite, we then calculate if their position is\nwithin the display area, and then we animate and add them to the draw list.<\/p>\n\n\n\n We could instead perform some kind of optimization. For instance, in the gameMap we not only store the tile value, but also a flag indicating the transparency of the tile, which is determined by the Editor. This allows us to quickly check if the tile must be drawn by DMA or CPU. That\u2019s why we use 16-bit entries for the tile map. Assuming a 256 tile-set (currently we have less than 128 tiles, but there is enough room in the flash to add some more), we have still 7 bits available, for other purposes. Three of these 7 bits could be used to indicate if there is stored any sprite\/object. For instance: <\/p>\n\n\n\n Then, we could create a\nbitmap table in RAM, in which each bit indicates if the item has not been\ndiscovered (for instance an enemy) or if it not has been picked up (e.g.\nbonus), or not activated (switch). In a 10×10-screen level, we would need 8000 bits,\ni.e. 1kB of RAM. The bit is cleared when the enemy has been discovered, or the\nbonus has been picked up.<\/p>\n\n\n\n In the\ncreateNextFrameScene() we would check the bits corresponding to the tiles in\nthe current view area. If these are at 1:<\/p>\n\n\n\n This has some drawbacks. <\/p>\n\n\n\n However, in this way we\ncould much more efficiently store and handle a lot of sprites in the level.<\/p>\n\n\n\n Still, this technique is more\nrelated to the \u201cgame logic\u201d part of the game, rather than the graphics engine!<\/p>\n\n\n\n We might implement later this feature.<\/p>\n\n\n\n Yes, for two reasons. We hoped you enjoyed this introduction.\nThere are still a lot of things we should and would explain. These will be the\nsubject of future articles.<\/p>\n\n\n\n In the meantime, you can download the full source code of the game! Please if you enjoyed it, consider of making a donation to ansimuz<\/a>, who is the artist that drew all the graphics and donated it to the worlds, for free! We won\u2019t reject donations either \ud83d\ude42<\/a> <\/p>\n\n\n\n The game is not complete\nyet. We still want to add audio, multiple levels, objects to interact with,\netc. Feel free to make your own modifications! We hope to see new games with\nnew graphics and levels!<\/p>\n\n\n\n The map editor will be released soon. It\u2019s too rudimental for now to be released to the public! <\/p>\n\n\n\n (Note! The video is taken at a much lower frame rate, due to poor ambient illumination! We will update the video very soon, to make you appreciate the full 40 fps speed!)<\/p>\n\n\n\n
On this computer, a very popular genre of games was the platform. Many of them were very colorful, featuring a very fluid parallax scrolling. This was achieved by talented programmers that ingeniously used the Amiga’s coprocessors to increase the number of on-screen colors. Take a look for instance at LionHeart!<\/p>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/lionheart.png\")
In the SAMD21 all this hardware is missing (except a rather simple DMA, at least with respect to Amiga\u2019s Blitter), therefore a lot of drawing stuff will be performed in software.
We would like to achieve these features:<\/p>\n\n\n\n
And they are, especially if asm code is ruled out!<\/p>\n\n\n\n
As for the hardware we will use uChip<\/a>, which is available on the Itaca Store<\/a> at https:\/\/shop.itaca-innovation.com<\/a>. <\/p>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/03\/bestUchipReduced.jpg\")
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/uChipPlayNotMounted.jpg\")
<\/figure>\n\n\n\nChallenges<\/strong><\/h2>\n\n\n\n
Memory<\/strong><\/h3>\n\n\n\n
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/Turrican.png\")
Timing – CPU<\/strong><\/h3>\n\n\n\n
xTilepos = cameraX \/ 16; \/\/ this is a rightward shift of 4 bits.
yTilepos = cameraY \/ 16;
destBufferAddress = &buffer[0][0];
for tile = 0...9
nTile = gameMap[yTilepos][xTilepos];
tileDataAddress = &tileData[nTile];
xTilepos = xTilepos + 1;
for y = 0\u202615
for x = 0\u202615
pixel = *tileDataAddress;
tileDataAddress = tileDataAddress + 1;
*destBufferAddress = pixel;
destBufferAddress = destBufferAddress + 1;
next
destBufferAddress = destBufferAddress + 144; \/\/ point to next row
next
destBufferAddress = destBufferAddress \u2013 ( 160 * 16 - 16); \/\/ now point to the position where the next tile will be saved.
next<\/pre>\n\n\n\nTiming – SPI<\/strong><\/h3>\n\n\n\n
\nWe use the version with SD card so that we will have plenty of space for other\nthings such as audio or additional levels.<\/p>\n\n\n\nThe graphics\ufeff<\/strong><\/h2>\n\n\n\n
How big will be each tile?
The size of each tile has strong impact on the memory consumption, details, and flexibility (and later we will see speed too).
Too large tiles will require to make a new tile for each small variation we would like to have. This would eat up storage memory.<\/p>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/twoTiles.png\")
Too small tiles would create the opposite problem. Bigger map tables, and lower speed.
Of course, we won’t be using silly choices like using tiles of 17×31 pixels. Powers of two are always your friend!
16×16 pixels is almost a golden rule, it is used in many games, and this is what we will be using!<\/p>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/transparentTiles.png\"){kind=spacer}
All this partially transparent stuff will be drawn by the CPU.<\/p>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/drawing.png\")
<\/figure>\n\n\n\nPipelining<\/h3>\n\n\n\n
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/graphisPipeline.png\")
<\/figure>\n\n\n\nThe DMA<\/strong><\/h3>\n\n\n\n
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/AnimazioneGip.gif\")
<\/figure>\n\n\n\nHow to store tiles<\/strong><\/h3>\n\n\n\n
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/TileOrdering.png\")
Display data block<\/strong><\/h3>\n\n\n\n
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/displayLneData.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/displayBlock.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/DisplayDescriptorUSage.png\")
<\/figure>\n\n\n\nThe background playfield<\/strong><\/h3>\n\n\n\n
The foreground playfield<\/strong><\/h3>\n\n\n\n
Putting together the two playfields<\/strong><\/h3>\n\n\n\n
Sprites and transparent tiles<\/strong><\/h3>\n\n\n\n
Vertical scrolling<\/strong><\/h3>\n\n\n\n
Hardware<\/strong><\/h2>\n\n\n\n
![\"\"](\"https:\/\/next-hack.com\/wp-content\/uploads\/2019\/04\/Schematics.png\")
Keys<\/strong><\/h3>\n\n\n\n
\nHowever we do not want to wait! Therefore we set the common line to a high\nimpedance state (so that no contentions occur), and we precharge the sensing\nlines to a logic value 1 or 0, by temporarily configuring them as output.\nLater, they are configured as input with pull-up or down respectively. Since\nthe output resistance is in the order of few tens of ohm, the state is forced\nin few ns, therefore, when the sensing line is configured back to input, it\nwill be already at the right state. After that, the common line is set to\noutput with the opposite polarity.<\/p>\n\n\n\nSPI connection<\/strong><\/h3>\n\n\n\n
Optimizations and further developments<\/strong><\/h2>\n\n\n\n
0b000 = no stored object
0b001 = opossum
0b010 = eagle
0b011 = frog
0b100 = gem
0b101 = cherry
0b110 = switch
0b111 = other future things, like secret walls that disappear.<\/pre>\n\n\n\nHey, you are saying that you are using 16 bits per pixel! <\/strong>
But I do not see 65536 colors onscreen!<\/strong><\/h2>\n\n\n\n
The first one is that the original tile set did not use 65536 colors. Yes, the original color space was 24 bits, but not every RGB combination was used! Probably the original author (ansimuz<\/a>) optimized the tileset for a 256 on-screen palette (actually we did not perform a color count!). Had the tileset been in black and white, you woud have seen just 2 colors, despite the 16-bit graphics operations! You are free (and encouraged too!) to change the graphics, and achieve more onscreen colors: this article is not about the particular pixel art graphics, but rather about the capability<\/em> of handling and showing 16bpp graphics at 40 fps, with dual playfield, parallax scrolling and onscreen sprites on a Cortex M0+ microcontroller.
The second reason is even simpler: the display has only 20480 pixels so at any time you’ll at most see 20480 different colors onscreen. Unless bizarre color combinations are choosen, you’ll never see that many different onscreen colors from a 16 bit palette… Still, this does not mean that, in the whole level, you won’t be able to see all the 65536 colors (that would be still very difficult to achieve, but only from an artistic viewpoint). <\/p>\n\n\n\nSummary<\/strong><\/h2>\n\n\n\n
Video<\/h2>\n\n\n\n