Billy's spring2019 Journal
Back for round two!
Guess who's back? back again… it's me, hey.
After successfully connecting my new hitDetection code with my now significantly shorter main program, I've come across a standstill, literally. As soon as the selection screen is passed and the game commences, the game pauses entirely. I can only assume this is due to something between my new function and the main program. I tested to see if getting rid of all of the hit detection would help but it didn't seem to improve anything. I've decided to start with the bare bones of the project with just the main two characters and build up until I find the issue.
While coding the mechanics for the portals, I came across a difficult hurtle. For some reason, my portals occasionally kill me. Trying to fix the problem, I improved upon the hit detection for teleportation so that as soon as the player comes into contact with the portal, they are teleported to the out portal with the same relative positioning they would have with the in portal. The first run was perfect, whenever I touched a in portal I was successfully teleported to the out portal. However, the positioning I had for the in portals at that time were not correct so I readjusted their x coordinates and after my next run, something went wrong and now all of the portals inflict instant death upon the player. However, the only way we have deaths programed is by the spikes, so that must mean that the teleporter somehow teleports the player into the space of the spikes.
The name of the game has changed this week as the focus of my efforts have shifted from expanding on our ideas on the game to finding out simplistic ways of reducing the size of my code. Due to the hardware limitations of the NES, I need to be careful about how my code is structured. Once I began looking at my code to see what I can slim down on it, I was able to eliminate a few dangling variables such as asteroidTimer, which I simply replaced with the already existing main clock. After looking over Haas' code for his pong game, I've been playing with the idea of making a separate function for hit detection in which I pass a struct comprised of the x and y coordinates of the two objects.
Last week I mentioned that the boss level will involve circling Nunia while he throws spikes at you. It turns out it the looping was as simple as I was expecting it to be. Once an object touches the edge of the screen, it is teleported far right off of the screen, imitating repeated ground. Although the platforms will already be set on the map, Nunia will launch spikes from the sky in set up locations. To damage Nunia, the square must climb the platform stairs and hit him on the head Mario style. When he takes damage, things will get more difficult however. On the first hit he will break the platform stairs so you can no longer climb that way. Instead you must use portals to climb the distance. Afterwards, Nunia will put his own portals next to yours, making it difficult not to slip into his portal and fall into some conveniently placed spikes.
This week we unveiled our demo to the class and added some general fixes. In particular I went through and fixed the missiles and asteroids falling along the side of the screen when not in use. Apparently I had not actually set the active variables off so they just continued to fall. In addition, I added a powerup sprite that looks like a UFO.
With the base code of our game finished, the main goals of this week and the following weeks are to create multiple levels for our game. At the moment, the first level is just about complete. However, we plan on having at least one more regular level, along with a boss level in which you circle Nunia until you have the opportunity to jump on his head. Although there will be platforms already on the map, Most of the obstacles will be thrown from Nunia themselves. With three sprites, we should be able to animate Nunia throwing things at us.
These past two weeks have been very eventful for our asteroids game! To start off, the base game is complete minus power-ups actually doing something after it is hit. However, that does include the shooting mechanics, the enemy projectiles, and the frame work for three separate game modes: single player, two player co-op, and two player versus. The scoring system and main menu have both been added, however there are no visuals yet to these components. Honestly, this project has been pretty straight forward; the only thing that put up a challenge is the inefficiency of using arrays with the NES system. Without the use of arrays, I've had to code the hit detection for Earth, two players, twelve missiles, six asteroids, two satellites, and a power-up. It wasn't necessarily difficult as much as it was time consuming, and frustrating when I have to spend a portion of my time looking for typos or one too many or too little brackets.
With the original deadlines for both of my projects moving until the end of the semester, we've already made a large amount of process. To start, all of our hit detection has been smoothed out and fine tuned. This includes all of our obstacles such as spikes, platforms, portals, and oil slicks. In addition to the map that we have, we plan on adding a couple more maps as well as a boss level with the notorious troll. For the troll level, I've contemplated having the main character “circle” the boss, hitting its head when possible. this wouldn't be too difficult if we make sure to feed the treadmill back into itself once it has exited through the left side of the screen.
This week I made a very good amount of progress. To start it off, our sprite can shoot its projectiles which can come in contact and react correctly with everything we have in the game now including the asteroids, the satellites, and the powerup. The asteroids make impact on the planet or the player at the moment. In addition, the asteroids, satellites, and powerups are all set on a timer that shoots the asteroids downwards, and the satellites and powerup horizontally. To make the week even better, Dylan came through with his wonderful random number generator that allows the asteroids to be shot randomly from the upper end of the screen.
I've gotten SDL on my laptop which should allow me to speed up the coding process from home. However, it isn't as easy to run SDL on my windows computer as opposed to the linux style pods. To simulate this environment, I've also downloaded code CodeBlocks. However, it does not have any compiler downloaded. I wonder if I can look on lab46 and find the compilers there.
With new advancements this week for asteroids, we're one step closer to getting 1.0 out for Haas! In particular, I've been able to get the shooting mechanic fully functioning for the player. At first the biggest issue was setting up the code to have a minimum time between shots. However, by thinking about the issue in a different light, the answer was easier to understand. Instead of thinking of the code as a timer, I've been thinking about it as a charge. Once the charge is full, a shot is able to be projected and the power that the player had is reset.
This week, we had difficulty setting up the surface application functions to run with our obstacle arrays. In particular, trying to access the x and y coordinates inside of the struct seemed to disrupt the computer. To resolve the issue, we have two arrays for the coordinates of all of the obstacles from the spikes to the oil slicks to the portals. Although all of the different types of obstacles are in their own arrays, all of their x and y coordinates are in the same arrays. To access the coordinates that are past the spike coordinates (the beginning of the arrays), simply up the variables that come before it with the “*size” variables that we have for the obstacle arrays.
Important tid-bits: *when you compile a program, a preproccessor such as the cpp looks through your code and makes substitutions for intermediary between the coder and the computer
*the compiler checks for syntax and changes the code into assembly
*Organizing code should generally be done by separating your text and data sections on either side of the memory space allocated for your program
*loops are essentially just jumps to the beginning of a segment of code that should be re-executed
*Interrupt vectors such as reset.s are interrupt codes to get the attention of the cpu
*alt-d for the debugger on mednafen
*alt-shift-1 for inputting controller buttons onto mednafen
*The Zero page contains the first 256 bytes
-jmp - unconditional jump or branch
-store(push) - takes from register and stores into memory
-load(pop) - takes from memory and stores into the register
-reset.s - pre-instruction to start the code. Puts the cart on the tracks
I've been looking over testfall to understand what exactly would be best for fall detection. At first, I've been using a new SDL_Rect to check and see if the player has fallen past the bottom of the screen, but it's possible it'd be easier to just use the dimensions of the screen ilp since it's already been made in memory.
While coding the sprites in our asteroids game, we noticed that we couldn't use arrays for our missile sprites. This is due to the expensive multiplication that the cpu needs to do in order to access these arrays. In this situation, I decided to try the hit detection without any arrays. Although it seems complicated, it does have a kaleidoscope pattern that makes it easier to follow. However, a different coding solution we could have executed was using a struct of arrays so the cpu does not need to run the multiplication.
Looking at our array of obstacles, Brandon and I discovered a strange reaction the computer makes to our code. When variabizing our computations, we found that the apply_surface method has issues with the first two inputs being from inside one of the members of the array. At first we knew we needed to use another variable but we weren't sure. In the end we decided to have an x and y array to hold the necessary information.
While adding the shooting mechanisms for the asteroids game, I came to a particular crossroads. My first plan was to simply have 3 shooters on the left, right, and upper spots on the map out of view. The left and right shooters would move up and down while the upper shooter would move left to right. I wonder how the constant manipulations of the shooters would effect the run time of my game. More importantly however, it would be easy to discover the patterns and deduce when the asteroids would come before they were even shot out. I then decided that there should be multiple shooters on each side of the map. They would all stay in place next to each other and they'd fire in different speeds. Writing this general gave me an idea for another alternative. Does the code even need shooters for the asteroids? The shooters were being used for a position to shoot from in space. With a static map, we already know what coordinates there are so we could just send the asteroids to those coordinates and begin its voyage. Also, while the starting y-coordinate will be locked, the x-axis will be constantly changing so the asteroids fall at various points in the screen.
While break wasn't very productive in terms of coding, I'm excited for what the next 5 weeks have in store. Now that Tuesdays are officially make your own video game day, Dylan and I will be making our own twist of asteroids meet space invaders. Although I do have a majority of the explanation on the course page, I left out some pending head cannon I have for the game. I was thinking about having the 2nd action button be a screen wipe a la space bomb on a charge.
Brandon and I have decided, after being given the opportunity to make our own video game on Tuesday classes, to make our own take on games such as Geometry Dash. Although I laid out a brief explanation of the game on the course notes, I did leave out some pending information. In particular, I was playing around with the technical execution of the illusion of movement in the game. Instead of the square moving and the ilp moving along with it on a long map, we could instead have the square running on a treadmill that will generate the necessary platforms and obstacles. These objects will be thrown left while the square stays in place.
Continuing on from where we left off, we had also added walls around the edge of our program. With the sprites saved into memory, the corresponding wall sprites could be placed around the outside of our program through a function we made for this purpose called DrawBackground. We've also now been able to create two player sprites, 100 pixels off of one another. This was done by going through the general defaulting of our sprites twice, including the sprite models for the missiles that each sprite shoots.
After our victory making the cat chase the mouse on the mudkip fin, it was time to step things up and add some timing into the mix. the SDL grouping has a type for timers called SDL_TimerID. Equating this to the result of SDL_AddTimer allows you to execute a line of code after a specified amount of time. For many games, updating too quickly can be a real issue; computers respond much more quickly and without cease comparatively to a human, so giving the computer a rhythm in tune with the speed of a human gives users a better experience.
Continuing on from where we left off, we decided to add a sprite to the program that we can move around with a controller. This sprite is under the type of sprite_t, allowing it to have a few conditions such as its x and y coordinates. The input ports for the controllers are established in the reset file. Each of the 8 inputs for the nes controller are held between 0x01 and 0x80. By reading what the controller inputs a direction, the corresponding x or y coordinates on the sprite can be changed to move it around.
After last week's progress of making a movable cat sprite on a mudkip fin, we've turned to enhancing how exactly we interact with the cat. Originally, we could only move the cat once with each button press of the arrow keys with an unsigned int that uses the function SDL_GetKeyState() to acquire the data that the buttons are sending out. However, with SDL_MOUSEMOTION, we are able to actually have the cat chase our mouse cursor!
Humorously, the end to our first week began with learning the differences of c-programming and using c to program in assembly. As is tradition when working with a new language or in this case level, the hello world program is great for making your first few steps. However, once we were done with this task, we found ourselves looking at over 40 lines of code for such a simple output! We are essentially main when writing our nes code, so a large portion of the program deals with the actual addressing of each bit that we require to execute said program.
As January approaches its end, we've already made a ton of progress. In our quest for making a playable video game, we've not only made a window with a programmable background and icon, but we've also created a sprite with a 3 frame stride in four directions. We did this by using a reference page for a cute cat sprite. By mathematically dividing the reference page we were able to single out each sprite and set the sprites up with the controls to make a fully movable sprite! However, it is only with button clicks so holding the button down is as effective as clicking it.
It was my first day back and I'm already pumped for this semester! Our major focus is going to be debugging Super Mario Bros of all holiness and then seeing what we can do in the same manner. However, while doing some homework on some possible emulators, I noticed that my computer would not access the link to FCEUX in the Fritzvd site due to an invalid security certificate. However, I can access the homepage of the site the link is trying to access. (Possibly old link)
To finish off my first day back, we delved into SDL and printing images onto the screen. While this is just the first step, I am very excited by tomorrow's agenda which includes trying to make an image bounce around the screen! Farther ahead I'm sure we'll also be working with events which will rocket us closer to our ultimate goal of making our very own game.