next »

[Ivan]

I've written NES roms in 6502 ASM, so I can provide some insights into doing it.

[r.kachowski]

could someone with the skills possibly give a guide to what's going on in this example from the gbdk package - and answer some nooby questions?

galaxy.c

i would like to know what needs to be initialized, where the sprites are drawn and what's going on in the main loop.

also, are the _data arrays the pixel information for each sprite/frame? how are these defined with regards to dimensions and framerate?

[Solved]

Definitely going to try to participate with this one. I will be using asm. I've started to make a title screen and I'll probably learn how to make a noise sometime this week.

Question: What does setting the timer modulo do? I assumed the timer modulo was the time between timer interrupts, but it seems to be the opposite, the higher the timer modulo the less time between interrupts.

[Cthulhu32]

could someone with the skills possibly give a guide to what's going on in this example from the gbdk package - and answer some nooby questions?

galaxy.c

i would like to know what needs to be initialized, where the sprites are drawn and what's going on in the main loop.

also, are the _data arrays the pixel information for each sprite/frame? how are these defined with regards to dimensions and framerate?

Oooh thats a pretty cool one. I'll possibly break that one down, because its using a few interesting methods of doing sprites that we could apply to our own demos. One of the important parts is understanding the while(1) loop, thats the update function of the entire program. If you can understand what is being called there, the rest should be easy to understand as its mostly initting.

Definitely going to try to participate with this one. I will be using asm. I've started to make a title screen and I'll probably learn how to make a noise sometime this week.

Question: What does setting the timer modulo do? I assumed the timer modulo was the time between timer interrupts, but it seems to be the opposite, the higher the timer modulo the less time between interrupts.

According to the Gameboy Programming Info, Timer Modulo is the number thats loaded into Timer Counter every time Timer Counter is overloaded.

http://fms.komkon.org/GameBoy/Tech/Software.html -
"The contents of TIMEMOD are loaded into TIMECNT every time TIMECNT overflows."

I'll describe it more when we hit the month of HCC

[Solved]

Definitely going to try to participate with this one. I will be using asm. I've started to make a title screen and I'll probably learn how to make a noise sometime this week.

Question: What does setting the timer modulo do? I assumed the timer modulo was the time between timer interrupts, but it seems to be the opposite, the higher the timer modulo the less time between interrupts.

According to the Gameboy Programming Info, Timer Modulo is the number thats loaded into Timer Counter every time Timer Counter is overloaded.

http://fms.komkon.org/GameBoy/Tech/Software.html -
"The contents of TIMEMOD are loaded into TIMECNT every time TIMECNT overflows."

Of course, I get it now. I assume that the Timer Overflow interrupt happens whenever the value of the timer counter becomes more than 255 and the 8 bit variable it is stored in overflows. So if I set the timer modulo to 255, this will happen every count of the timer, at 254 every 2 counts and so on.

[Cthulhu32]

Here's another teaser for anyone who wants to get a little more hardcore:

http://gameboy.modermodemet.se/en/demos

particularly
Space Waste by Octarine - http://gameboy.modermodemet.se/en/demo/1
That thing comes with full source, not sure what compiler he used, but its all in ASM.

I think I'll have like 3 levels of challenges, and for the advance challenge I'll have a "make a plasma effect" or something. That way we can try to get all levels of programming expertise.

[Hideous]

Plasma effect in 4 shades of grey is going to be hard.

[roboprez]

Plasma effect in 4 shades of grey is going to be hard.

Now that would be cool!
I may skip out this month's challenge and brush up on my c/c++. I've never actually done anything other than actionscript or gml and I don't think either of those are any consoles native language.

[Cthulhu32]

I wanted to try out GBDK a bit to before I started getting into the first month and got people into this. I've actually discovered quite a few bugs and quirks about the C compiler that I can share when the month comes, and I worked through porting the 1 hour tetris clone to the Gameboy Color. (http://www.gamedev.net/community/forums/topic.asp?topic_id=192483)

Here is the demo rom as of 1-15:
 http://cthulhu32.kraln.com/misc/hcc/gb/tetris.1-15.gb

The rotations are chuggy and the colors are pretty harmful to the eyes, but its the first iteration so I just wanted to show it off a little :D I'll release source once I get the speed up to snuff, and I'll probably add a menu and everything so I have some basis to do a few tutorials.

[ArmchairArmada]

I've been wanting to do some small retro projects for fun.  Years ago I've played with GameBoy and GameBoy Advance C compilers.  I remember it was very easy to get a sprite moving around and interacting with a tilemap.  I've learned a lot more about game development since then and am curious about what I might be able to accomplish now.

One machine that I have a nostalgic fondness for is the Commodore 64.  I hope we get to visit a number of the old classic consoles, computers, and handhelds of the past.

[Cthulhu32]

I've been wanting to do some small retro projects for fun.  Years ago I've played with GameBoy and GameBoy Advance C compilers.  I remember it was very easy to get a sprite moving around and interacting with a tilemap.  I've learned a lot more about game development since then and am curious about what I might be able to accomplish now.

One machine that I have a nostalgic fondness for is the Commodore 64.  I hope we get to visit a number of the old classic consoles, computers, and handhelds of the past.

Yeah I was going to start with something in C so people would not be overwhelmed by the ASM. Also game consoles like the Gameboy and Nintendo DS have locations in memory specifically designed for sprites, backgrounds, layers, etc. So the hardware itself is lending you a hand as you program, taking care of the sprite/tiling details.

The Commodore 64 also has sprites and tiling, but its a bit more complicated. If you want a head start for when we get to the Commodore, here's a programmer's reference manual (all code examples are in Basic.)

http://www.commodore.ca/manuals/c64_programmers_reference/c64-programmers_reference.htm

[ArmchairArmada]

The first computer I learned to program on was an old Commodore 64 my uncle gave my older brother.  I know a good deal about the computer's capabilities and limitations.

My biggest complaint about the Commodore 64 is how hard screen scrolling is.  It would require a highly optimised assembly routine to move screen data since the hardware only lets you scroll the screen eight pixels vertically and horizontally.

I had this idea of using run-length encoded redefined character map screens that can be scrolled either horizontally or vertically (depending on line orientation), then only the beginnings and ends of the lines need to be changed when the screen is scrolled -- thus significantly reducing the number of reads and writes to memory.  The major drawback with this would be repetitive looking graphics, but it might not be too bad if done right.

Alternatively, it might just be a good idea to avoid scrolling and simply use rooms instead.

[Cthulhu32]

The first computer I learned to program on was an old Commodore 64 my uncle gave my older brother.  I know a good deal about the computer's capabilities and limitations.

My biggest complaint about the Commodore 64 is how hard screen scrolling is.  It would require a highly optimised assembly routine to move screen data since the hardware only lets you scroll the screen eight pixels vertically and horizontally.

I had this idea of using run-length encoded redefined character map screens that can be scrolled either horizontally or vertically (depending on line orientation), then only the beginnings and ends of the lines need to be changed when the screen is scrolled -- thus significantly reducing the number of reads and writes to memory.  The major drawback with this would be repetitive looking graphics, but it might not be too bad if done right.

Alternatively, it might just be a good idea to avoid scrolling and simply use rooms instead.

Ahh cool, so it'd be very nostalgic for you as well to do some C64 programming :D

Scrolling is definitely more challenging as you have much less space to work with. I googled it a bit, and found this: http://www.c64.ch/programming/c64prg10.txt  but I'm not sure if thats exactly what you'd need to do the full tile routine.

Code:

 SMOOTH SCROLLING

    The VIC-II chip supports smooth scrolling in both the horizontal and
  vertical directions. Smooth scrolling is a one pixel movement of the
  entire screen in one direction. It can move either UP, or down, or left,
  or right. It is used to move new information smoothly onto the screen,
  while smoothly removing characters from the other side.
    While the VIC-II chip does much of the task for you, the actual scroll-
  ing must be done by a machine language program. The VIC-II chip features
  the ability to place the video screen in any of 8 horizontal positions,
  and 8 vertical positions. Positioning is controlled by the VIC-II
  scrolling registers. The VIC-II chip also has a 38 column mode, and a 24
  row mode. the smaller screen sizes are used to give you a place for your
  new data to scroll on from.

  The following are the steps for SMOOTH SCROLLING:



  128   PROGRAMMING GRAPHICS
~


  1) Shrink the screen (the border will expand).
  2) Set the scrolling register to maximum (or minimum value depending upon
     the direction of your scroll).
  3) Place the new data on the proper (covered) portion of the screen.
  4) Increment (or decrement) the scrolling register until it reaches the
     maximum (or minimum) value.
  5) At this point, use your machine language routine to shift the entire
     screen one entire character in the direction of the scroll.
  6) Go back to step 2.

    To go into 38 column mode, bit 3 of location 53270 ($D016) must be set
  to a 0. The following POKE does this:

    POKE 53270,PEEK(53270)AND 247

    To return to 40 column mode, set bit 3 of location 53270 ($D016) to a
  1.The following POKE does this:

    POKE 53270,PEEK(53270)OR 8

    To go into 24 row mode, bit 3 of location 53265 ($D011) must be set to
  a 0. The following POKE will do this:

    POKE 53265,PEEK(53265)AND 247

    To return to 25 row mode, set bit 3 of location 53265 ($D011) to a 1.
  The following POKE does this:

    POKE 53265,PEEK(53265)OR 8

    When scrolling in the X direction, it is necessary to place the VIC-II
  chip into 38 column mode. This gives new data a place to scroll from.
  When scrolling LEFT, the new data should be placed on the right. When
  scrolling RIGHT the new data should be placed on the left. Please note
  that there are still 40 columns to screen memory, but only 38 are
  visible.
    When scrolling in the Y direction, it is necessary to place the VIC-II
  chip into 24 row mode. When scrolling UP, place the new data in the LAST
  row. When scrolling DOWN, place the new data on the FIRST row. Unlike X
  scrolling, where there are covered areas on each side of the screen,
  there is only one covered area in Y scrolling. When the Y scrolling


                                                 PROGRAMMING GRAPHICS   129
~


  register is set to 0, the first line is covered, ready for new data. When
  the Y scrolling register is set to 7 the last row is covered.
    For scrolling in the X direction, the scroll register is located in
  bits 2 to 0 of the VIC-II control register at location 53270 ($D016 in
  HEX). As always, it is important to affect only those bits. The following
  POKE does this:

    POKE 53270,(PEEK(53270)AND 248)+X

  where X is the X position of the screen from 0 to 7.
    For scrolling in the Y direction, the scroll register is located in
  bits 2 to 0 of the VIC-II control register at location 53265 ($D011 in
  HEX). As always, it is important to affect only those bits. The following
  POKE does this:

    POKE 53265,(PEEK(53265)AND 248)+Y

  where Y is the Y position of the screen from 0 to 7.
    To scroll text onto the screen from the bottom, you would step the low-
  order 3 bits of location 53265 from 0-7, put more data on the covered
  line at the bottom of the screen, and then repeat the process. To scroll
  characters onto the screen from left to right, you would step the low-
  order 3 bits of location 53270 from 0 to 7, print or POKE another column
  of new data into column 0 of the screen, then repeat the process.
    If you step the scroll bits by -1, your text will move in the opposite
  direction.

  EXAMPLE: Text scrolling onto the bottom of the screen:

start tok64 page130.prg
  10 poke53265,peek(53265)and247        :rem go into 24 row mode
  20 printchr$(147)                     :rem clear the screen
  30 forx=1to24:printchr$(17);:next     :rem move the cursor to the bottom
  40 poke53265,(peek(53265)and248)+7:print :rem position for 1st scroll
  50 print"     hello";
  60 forp=6to0step-1
  70 poke53265,(peek(53265)and248)+p
  80 forx=1to50:next                    :rem delay loop
  90 next:goto40
stop tok64

[ColossusEntertainment]

We have a couple of basic tutorials on C64 programming over at www.retrogamedev.org, which might be of interest 

[Average Software]

I've started working on my Atari 5200 project, and I thought I'd post it here if anyone is interested.  You can check it out from my source repository at:

svn://averagesoftware-uniserver.no-ip.org/svn/tetrax5200

It's in 6502 assembly, and should be assembled with DASM.  An assembled ROM is included in the checkout.  Right now it just has a goofy looking sprite that you can move left and right.