Francois's projects

Background sound added

2010-07-06T13:39:00.003-04:00

Sometimes, the small details make a big difference. That what a background sound in a game is. I decided to add sound mixing feature to my sound manager and I think the demo is way better with it. See for yourself in the following video.

Complete Megaman + USB + Sound demo

2010-07-03T12:15:00.005-04:00

Major update on the console project!
Yesterday I finished (for the most part) the USB stack and the Xbox360 controller driver and I've been able to make it work with the Megaman demo.

I was stuck with a synchronization problem but it turned out to be a problem with my toggle bit on data packets. This is a bug very hard to find since even with the wrong data toggle I was getting no transmission errors. Now I still have to clean up my code a little but it should be really quick.

From now, the next big thing I have to do I isolate the game from the kernel and load the game from the SD card instead of bundling it with the kernel on the chip.

Here's the demo

Bluescreen SUN7

2010-06-09T09:49:00.006-04:00

Yesterday I finally received my BlueScreen SUN7 from ThaiEasyElec. It took 4 days to ship from Thailand to Montreal but thanks to DHL it got stock 1 week in their depot. Anyway from now I'll be able to continue my tests without being scared of my board catching on fire (see last post).

This board has a really nice look with the screen now on a different PCB. And don't worry I just tested it and it's backward compatible with your BlueScreen SUN code. What that means is that you can run your code on the SUN7 without any modification. Of course if you do that you won't be able to use the extra IOs on the board since these new IOs are, for the most part, the unused LCD pins. Unused LCD pins? Yes I forgot to mention that the screen is now locked to 18bit color instead of 24. This is because they are now using the same controller for both 4.3 inches and 7 inches and the 7 inches screen is 18bit color. I didn't do any intensive testing on that but I'm pretty sure that it's really hard to see the difference between 18 bits and 24 bits (for the human eye), except maybe for the green shades. It is also worth mentionning that the SUN7 has an Ethernet port built in but the USB device port is gone. Who wants a USB device port anyway?

A little more on the console project now. In the video, I'm showing my broken USB host code. You'll se that it's able to detect devices but it's not able to "talk" (read communicate) to them. I'll shoud fix that pretty soon and then I'll be able to finish that tiny USB stack.

ThaiEasyElec excellent support

2010-05-26T12:01:00.007-04:00

On May 23rd I was working on the project as usual but more precisely on the game sound effects. As you saw in a previous post the sound section was working but only in a synchronous manner. In other words, if used in a game, the game would stop until the sound is played only to continue at the end of the sound. That's surely not what we want.

But then when I started one of my multiple tests the backlight of the screen started flickering. For those who don't know, I'm using a BlueScreen Sun board from ThaiEasyElec. I was starting to worry so I turned off the board and saw that one of the inductance involved in the backlight circuit was overheating.

This is a big problem for me since I'm working full time on this project now and I need to test my code all the time. Furthermore, since this project has to be finished in a couple of months, the time is running out.

I immediately wrote an urgent email to ThaiEasyElec to ask them to help me. I don't know how they do it but they almost always answer within 10 minutes even if their time zone is close to 10 hours ahead of mine. They told me right away that they would help me. I was relieved and that stopped me from worrying for the sake of the gaming console project.

Now a couple of days later they are supposed to ship me a new board so I can continue my testing. In the mean time, I can continue using my current board for really quick tests so I think that this won't even affect the project after all. Thanks to the ThaiEasyElec team!

So why am I telling all that. Well first to keep you updated on the project. But the main reason is because this company is not well known in America and you might be scared to buy from them since it's really far away but don't. They have really good products at very low cost that you can use as a learning tool, a prototyping board or even in your end product. If you check their website you'll see that they offer a whole bunch of other services that might suit your needs. Ok ok enough publicity...

Thanks again ThaiEasyElec!

Game Engine : Collision detection + transparency

2010-05-22T11:55:00.003-04:00

Lots of new things today!

First the collision detection. For now the detection algorithm is pretty basic and it checks for collision for the whole picture square. I'm not going to go into the details but if you want more information just check gamedev.net. I'm using their first algorithm. Anyway it doesn't really matter what I'm using for now since, thanks to object oriented programming, you just have to change one place and the whole game will use the new algorithm.

The interesting part is how I tell the sprites that they collide with some other sprite. For that I'm using a modified version of the visitor pattern. You can have more information there.

Then there is the transparency. As I though, it was pretty straightforward. I only added a black and white mask for every pictures and then did these two logic operation :

VideoMemory AND Mask
VideoMemory OR Image

This is the same thing as if you would want to set a register to some value at runtime.

So as usual, here's a video of all that in action:

Game Engine : Enemy spawning

2010-05-15T19:16:00.003-04:00

I worked a lot today to add enemy spawning to the console. It was somehow difficult since I have to keep track of where I have to spawn enemies but once spawned I have to let them loose until they get out of the screen. To do this I put the Sprite into a SpriteContainer to add some more information to the Sprite like the spawn position and whether it's been spawned (active) of not. Then when the sprite gets out of the screen I remove it from the active sprite list and it can then be spawned again if the hero run into the spawning area if this sprite.

Take a look at the video to see the result.

Game Engine : Final hero only demo

2010-05-12T20:54:00.002-04:00

This should be the last hero only demo. There is nothing new here except that all the left states are implemented so the hero can go on both side. I'm not even talking in this video since there is nothing to say. On the next update there's going to be either sound effect, enemies or transparency. These are the 3 things I need to work on next.

Game Engine : Gravity

2010-05-12T08:15:00.003-04:00

Yesterday I worked quite a lot on the game engine and added the gravity to the game. So now Megaman is able to jump and fall according to the current gravity. I don't feel like explaining a lot in this post since I still have a lot of work so here's the video right away.

720p video!

2010-05-08T11:16:00.004-04:00

I finally did some more tests with my lifecam cinema and I now able to record at 720p 30fps so that's going to upgrade my video quality a lot. Here's an HD embedding test.

Hero running right

2010-05-06T03:16:00.003-04:00

Today I added a new state and some state transitions that permit the hero to run right and stop. For now, there is no ground detection though but that should be implemented soon. Here a little video to show all this in action.

As you can see there is still some white around the hero but I'll fix that when the hero is going to be fully functional.

Hero rendering

2010-05-04T13:11:00.004-04:00

I was not supposed to spend time on the console this week but I still did some work. For the first time now we can render a hero. For now everything looks static but I can assure you (nothing's stopping you from looking at the code) all of that is pretty dynamic indeed.

I used the state pattern for the hero movement and rendering and for now I only implemented the HeroStandingRight state so that's why nothing's moving. That only a matter of time before I implement the other states and I think from now it's going to be pretty quick.

As for the white around the hero I'll fix that at the end when I'll have a hero running and jumping. I'll use the common masking technic so it should be pretty straightforward.

I think the hero rendering stuff what the hardest part remaining for the gaming engine. All the other sprite handling should be a simplified version of the hero handling. Except for the final optimisation of course, that should take a while.

First reflow soldering

2010-05-04T12:45:00.007-04:00

Last Sunday I tried to solder a SOIC chip on a DIP adapter and for the first try I think it went pretty well. I just put a little too much solder paste but that's it. Hopefully now I'll be able to stop using my cheap soldering iron.

Here's a few pictures.

Tile and background rendering

2010-04-28T15:36:00.002-04:00

Yesterday I added the background rendering to the game engine but after some testing I figured it was running way to slow. So today I worked the whole day trying to optimize that and it worked out pretty well. Actually now the slower part it the tile rendering. To achieve this I used a DMA channel which is a lot faster that manual refreshing of every pixel.

Since the background is scrolling, the source addresses are changing on every refresh so I still have to loop a little before every DMA transfer. However, I optimized it like crazy to help the compiler and right now it's literally one step before assembly. In other word, I wrote the C code as if I was going to translate it to assembly so it's really easy for the compiler to optimize the code . On the other hand, the code is now really hard to read but I left the good looking version commented in the file.

There is one major drawback to this optimization which is the background now needs to have some specific dimensions. For instance, the background needs to be 256 pixels wide and repeat itself 3 times inside the same BMP file. This means that the actual image file is 768 pixels wide. For now this big file is hard to load into memory but once again there is a lot of possible optimization. First I could use DMA transfer to copy the file from the SD card to memory. Then I could optimize my BMP handling code which could probably be a lot faster.

Here's a quick video of the result.

Tile rendering (cont.)

2010-04-27T09:12:00.005-04:00

I was kinda in a hurry when I did my last post and I think I forgot some important details. Here's some more information. First, this is what I'm rendering with some additional lines so you can see the actual tile array.

With this you can see more clearly that the tiles on the right are not rendered completely. The same thing apply to the bottom of the bottom tiles. And just to be sure that you get all the information, here are the two tiles I'm using in this demo. These are the only image loaded in memory.

Tile rendering

2010-04-26T13:17:00.003-04:00

I just finished my exams and I'm now back on the console project. This morning I did most of the tile rendering stuff along with the side scrolling.

More precisely, I can render tiles of any rectangular dimension. The rendering function can handle tiles that are partially visible on the screen and all that with double buffering so there is no screen flickering.

On the picture below I used tile of 56x32 pixel. This means that the last tile to the right is not completely displayed. Furthermore, all the bottom of the second row is not displayed as only 71% of them is required to fill the screen. I think that this example tests all possible cases and I'll be able to start working on something else right away.

The next step is probably the background rendering which shouldn't be too hard. Then I'll start the sprite rendering.

Sound on the console prototype

2010-04-03T22:25:00.003-04:00

Here we are now with another update. Even though I'm at the end of the school semester, I'm in a coding spree for that console. I think it's more like an addiction at that point. Anyway. So as stated in the title, I got the sound running. This is pretty cool since it's one of the last "risky" thing that I had to do. I say risky because I've never done it so it was possible that I would run into something that seemed possible at first but impossible in the end. That means that I can relax a little more. ;)

So for the sound I did pretty much like the Bitmap handling. I have some structures for the header of the file and a big array for the data. I load everything into memory from the SD card and I play it afterward. To play the sound on the micro-controller I use the 10bit DAC embedded on the chip. Although it doesn't sound that nice, it's good enough for my tests. We'll see later if we want to add a better DAC in the final version of the board. As always, this is an early test and I need to clean things up in the code. The first thing I'll do is change the dumb delay for a timer delay for the song playback. Hopefully it's going to be more precise and the sound won't be out of timing like in the video (The Megaman fans will notice that it's playing a little too slow).

Now I really have to put some more time in my homework so the next update may be in a week maybe more. After that I'll probably start working on the tile engine again so there is more to come.

Bitmap on the console prototype from SD card

2010-04-01T08:32:00.002-04:00

Up until now, when I wanted to display a picture on the screen of the BlueScreen Sun board I had to translate it to an array and dump it to a .h file. This was a quick and dirty way for fast testing. This is now part of the past since the SD card access is now up and running.

Here is some technical details.

First, the FAT32 handling is done using FatFs. This project is pretty active these days and I must say it's working pretty well. Furthermore, it's really easy to port since the low-level part can be easily identified and implemented. Talking about the low-level section, I did not even program it. Basically all I did was porting this which was only a matter of some define modification and some pin configuration. However, this doesn't look pretty since all my code is in C++ and this SD card handling code is in C. What I'm thinking of doing in a near future is keeping FatFs as-is but port the low-level section to C++ to keep things as constant as possible. All I would need is a C adapter calling my C++ functions.

Other than porting code, I did a Bitmap parser which is a Bitmap class that receive a file path in the constructor. This class is able to load the picture in memory and reformat it a little so it can be displayed easily. This class can later be used with my DisplayHelper class to display the picture on the screen.

As you can see on this video, it's working pretty well. However, some part of the code is still dirty so be warned if you check the source on the SVN.

Reflow oven finished!

2010-03-29T01:17:00.008-04:00

As you can see on the picture it's finally done. I had some problem with the reflow module at first but now it's fixed and everything seems to be working correctly. It is important to note though that I don't have any solder paste yet so I didn't do a real test but still the temperature curve doesn't lie. Anyway I should try to solder things with it pretty soon.

If you are curious, the reflow module is a techFX reflow 3.0 from thesiliconhorizon.com. It's a great temperature controller if you don't want to create one yourself. Furthermore, they have a crazy good support. I sent them quite a few emails and they replied most of the time within 10 minutes! Even sometime on the weekend. On the other hand I must that the PC application is nothing fancy and probably wouldn't get a good grade in a UI course but who cares right? The important thing is the controller which is able to stabilize the temperature within nearly +/- 1 Celcius.

Here's some more pictures of the oven hacking process:

Gaming console update

2010-03-23T19:22:00.003-04:00

It's been quite a long time since the last update so here's a little update to keep you posted on what's going on with the gaming console.

First, I figured out that my PLL configuration was wrong so the chip wasn't running at 72MHz. This is now fixed and everything is running much closer to my calculation in term of screen refresh rate. I don't think I'll have any problem to run a game at (kinda) high resolution but for now I'll stay close to the SNES resolution.

As for the tile engine, I'm still working on everything at once and nothing is close to a demo for now. There is still a lot to do before I can do some engine testing. Here is some kind of road map of my next steps on this project.

- Configure DMA memory-to-memory transfer that will be used to refresh the background and possibly foreground

- Configure SD card access to store some real pictures

- Configure DMA transfer for the SD card

- Handle FAT32

- Continue engine development

Tile game engine

2010-03-15T10:18:00.009-04:00

As mentioned in the previous post, I've been working on a tile game engine for the console and thanks to Louis Lynch, I have a solid starting point in therm of class model. As for the code, a lot of the basic stuff it done and I'm now slowly going through the rendering functions.

Since the screen is square, I'm pretty sure I'll be able to find a clean way to render the tile map but since I have problem finding it, I'll post about it and it will hopefully clear things up in my head.

In the upper picture you can see a typical case of tile rendering. The square array represent the tile map of the entire level and the thick line, the visible area i.e. the screen area. This is the known starting point of the rendering process. In other words, I have (x1, y1) and (x2, y2) of the screen area in pixel.

Here's a list of the problems I'm facing and some possible solutions.

Problem 1: All the tiles are stored in an array and know their position but these position are useless since it has to be relative to the visible area.

Possible solution: None

Problem 2: Not all tiles should be rendered completely.

Possible solution: Create a render mask and give it to the tile render function.

Problem 3: Tiles don't know where to render themselves on the screen. This is linked to the problem 1 since if they would know their position relative to the visible area, they would know where to render.

Possible solution: Send the render position to the tile render function. This kinda defeat the tile map function since even if two tile are next to each other, the environment could tell them to render in some other random position.

Hints:

All tiles on the same line should render the same height of pixel. Same apply for column and width of pixel.

Any suggestion? Anyone?

Projects update

2010-03-15T10:05:00.003-04:00

It's been a long time since I haven't posted anything and it's because I didn't reach any milestone in my projects. So here's a little more information of what's going on around here.

In the reflow oven project, I received the PID control module and somehow broke it after plugging it for about 20 seconds. I really don't know what happened but I shipped the module back and by now it should be close to its destination. The SiliconHorizon should try to fix it and tell me what went wrong with it. More on this soon.

Then in the gaming console project, I didn't find anyone to work on the gaming engine so I decided to try to do it myself. I did a little bit of research before taking this decision and it seemed that it was not that difficult and I though I should be able to work something out before the end of the semester. I'm actively working on that right now and I'll add some more information on the development in a different post.

Megaman X on the BlueScreen SUN board

2010-02-28T01:49:00.002-05:00

It late at night already but I just couldn't help myself. So here you have it, Megaman X running on the LCD. Note that for now I still don't have access to any kind of storage so all that is in a big 2D array in a .h file. Still, I think it's really cool!

Some fun with the BlueScreen SUN LCD

2010-02-27T19:03:00.007-05:00

After being waked up by some guys that wanted to give me religious fliers, I decided to play a little more with the LCD screen. I started by displaying some random math functions but then I figured I should stop wasting my time and get down to business by displaying 24-bit color pictures. Here's what I've done.

For this picture, it's the first time I actually take the time to create some kind of setup to hold the camera while taking a long exposure picture. I quite happy with the result though. By the way, this is a 1:1 picture of the game taken with zsnes.

Pixel = x * y

Pixel = sqrt(x^2 + y^2)

<
Pixel = x^2 + y^2

Ok maybe I have too much time on my hand (like Styx :P) but you have to agree that it's kinda cool to actually *see* math, isn't it?

The LCD is now up and running

2010-02-27T10:38:00.004-05:00

After working with the GPIO section I started coding the USB part which was according to my plan. But after some debugging, I though that it would be way easier to debug using the small LCD I had with the board. Anyway, how hard can configuring a LCD controller be? Well it is in fact not that complicated but to make it work I had to configure the SDRAM as well which was not supposed to be that soon. Anyway all that is working now and I have a little demo of it. It's not that great for now but at least its not a blinking led ;)

Gpio section ported successfully

2010-02-18T19:23:00.003-05:00

Today I tested the GPIO part of the framework on the BlueScreen SUN development board. I ran across a little problem when trying to create a new object. After some testing I found that my implementation of sbrk() didn't like the heap to be on top of the stack. I agree, putting the stack under the heap is not the standard way of doing things but that's how it was done in the linker script sample I got from NXP. Anyway I changed it with a quick and dirty fix for now but I'll try to do it the right way before committing it to the SVN. Other than that, everything seems to be working smoothly. I'm not adding any picture or video today since I'm tired of showing blinking LEDs. Don't worry though, the next thing I'm testing if the USB section which is going to be a little more fun to show.

Gaming console development Part1

2010-02-16T06:54:00.011-05:00

Apart from the reflow oven, I'm working on a gaming console project. The goal would be to create a small and low cost embedded platform where it would be fast and easy to develop 2D games like Megaman or Metroid. I had this idea after working on this project last semester. I first wanted to continue on the Cortex-M3 microcontroller since I had a great C++ framework to work with but there was two problems with that. First, software controlled display use a lot of CPU power. It is not impossible and it has been done already with some chip way smaller than the 72Mhz STM32 but I had a feeling that I was wasting the potential of the MCU. And that's not all. I wanted to have at least the power of the SNES and some SNES games are way largers than the 512Kbytes of the internal storage of the STM32 I was using. I could have taken the bigger STM32 which support external SRAM but then that would defeat the low-cost part of the project since SRAM is still quite expensive. So in the end I decided to go with the LPC2478 from Philips which has a LCD and SDRAM controller. I though about that for a really long time and I have a big sheet of paper here full of different MCU models with their pros and cons. If you think I made the wrong choice, don't hesitate to post a comment and we'll talk about it ;)

Before going further with this, I have to tell you that everything I've done for that project is on google code : http://code.google.com/p/armconsole/. Note that I'll use the same C++ framework than the Xbox360 controller interface project which is here : http://code.google.com/p/usbarm/. In these repository you have access to not only code but UMLs, sequence diagrams and even our final report in the case of the Xbox360 interface project.

For now, all I need to do is port the C++ framework from the Cortex-M3 to the LPC2478 including the USB part which needs a lot of work since I was using the MAX3421E with the STM32 but now the LPC has a OHCI compliant USB controller. I must say these two controller are quite different. This project will go mainstream next semester. I'll have one teammate that will focus on the hardware part and maybe another that will build or port a 2D game engine.

In case someone is wondering what I mean by framework, well it's just a set of classes that can abstract the hardware. For example, if I want to blink an IO pin, I do like this :

Gpio *gpio1 = LPC2478::getGpio1();

// Set default port behavior
GpioConfiguration portConfig(Gpio::INPUT);
gpio1->configure(portConfig);

// Configure blinking led
GpioPinConfiguration ledPinConfig;
ledPinConfig.pin = Gpio::OUTPUT;
gpio1->getPin(12)->configure(ledPinConfig);

GpioPin *led = gpio1->getPin(12);

// Blink led
while(1) {
    led->setHigh(); // On
    for(uint32_t i=0; i<100000; i++);
    led->setLow(); // Off
    for(uint32_t i=0; i<100000; i++);
}

For now, the GPIO section and part of USB is done. But nothing has been tested. I'll keep you posted on that. On the other hand, I managed to boot the chip and toggle an IO the low-level way which at that point is great! This means that the toolchain, Makefile, linker script and the bootstrap are all working correctly. As a side note, I'm using the same toolchain as when I was working on the Cortex-M3. If you would like some more information on that, you can read the article I wrote last semester.

So that's it for now. Here you can see a picture of the prototyping board I'm working on because we just like pictures :)

SSR mounted on the oven

2010-02-15T08:05:00.006-05:00

After having some fun with the drill, here is how it looks. There is really not much to say here except that I'm quite happy with the result.

Starting point of the reflow oven

2010-02-14T20:50:00.003-05:00

I've been working on a reflow oven project for a month or so now. I'll try to catch up with a series two or three posts. Basically I want to modify a toaster oven to work with the TechFX Reflow 3.0 temperature control module. Nothing that hasn't been done already but with a little luck this could end the soldering iron era for me.

So this is the first part of the project. You can see on the (bad quality) picture one of the side cover of the oven with a solid state relay and an omega big heatsink :) Just as a side note, I don't need a heatsink that big but I found the smaller one ugly so since it doesn't matter, here I am with the big one. These are coming from futurlec in case someone is wondering.

In the next post I'll show you all these together.

It starts.. (timon's voice)

2010-02-14T17:50:00.004-05:00

Ok, so I finally decided to have a blog on my projects. I think I'll start by posting about my current one and I'll maybe add some of my older projects later.

You should see some posts about the reflow oven and the 2D console I'm working on right now in the next few days.

Francois