OK, this is all good etc., but why limit to programming? Games need graphics and sound too. At least those I've played on the Mega Drive.
Printable View
OK, this is all good etc., but why limit to programming? Games need graphics and sound too. At least those I've played on the Mega Drive.
Sega´s Blast Programming hut?
Graphics and sound... nah, I believe the forum should be entirely dedicated to Zork clones and hacks, possibly mods as well.
Yeah, who needs graphics or sound in their Genesis games. Those Watermelon guys are out of their minds, damn whippersnappers! :D
I still believe in my Blast Programming vote. Come to think of it, that name has a nice ring to it.
Well, i approve that one too.Quote:
Originally Posted by Guntz
Maybe Blast Brewery:
-General / Programming
-Graphics
-Sound
-Homebrews
-Hacks
Blast Programming sounds pretty cool too.
It's open! I went with "Blast Processing" because any time I hear the term, I think of programming, processor speed, and things like that. All Genesis/Sega CD/32X threads dealing with programming, hacks, homebrews, graphics, flash carts, etc. should be posted in this new forum.
Enjoy!
Sweet! Really cool you chose my suggestion! :D
Best one.Quote:
Originally Posted by Doktor D
Can someone put into perspective for me what developing on a console is like? My impression is that learning the assembly code and developing for a console where you're writing low-level code and directly interfacing with the CPU and RAM is an extremely advanced "art".
I can't imagine that someone who has done "some BASIC programming" on their Tandy in the 80's is in a position to start coding for the Genesis. I, personally, can write code in a few of the common high-level languages but only for typical n-teir business/research-based apps where you're querying a DB and putting together a front end that talks to an app server, manipulating strings, etc. You don't deal with sprites, collision detection, and all that stuff normal business or scientific programming.
Isn't programming for a piece of hardware like the Genesis on a WHOLE 'nother level? I mean...I'd be ecstatic if I could write a Genesis game that was a red square that bounced around a black screen and blew up when it ran into a rectangle or something! That would probably take me weeks and months of hard work to develop too!
BTW, I do think this is a super addition to the site and would love to see some projects being developed here! :)
As someone else who spent the 1980s writing BASIC on a Tandy, I'm in a similar boat. I can say that, while I haven't used the Genesis version of BASIC (BasiEgaXorz), the BASIC variant that was developed for Atari 2600 (Batari Basic) is extremely easy to use.
On the VCS w/ bB, I was able to work up a multiscrolling game demo with music in about a day, and I don't really know a damn thing about programming games, though I'm fair-to-middlin' at music programming.
Programming for a console is really damn hard, but there's plenty of tools to make your life easier, even for the atari 2600. As mentioned by goldenband, Batari Basic is very easy to use. BasiEgaXorz is also pretty easy but I can't stand programming in classic basic :S, it's so limited you can be more productive working in a macro/hl assembler (like neshla, neshla is the greatest thing ever btw, check it out if you'd like to program on the NES).Quote:
Originally Posted by Yoder
EDIT: A bit of code visible on a photograph available on the original pier solar cd should give you an idea of what it's like (C code):
uchar shift;
ushort r,v,b;
register uint *pl;
pl = (uint *) GFXCNTL;
pw = (ushort *) GFXDATA;
if (nb0 != 0xff)
{
*pl = GFX_COLOR_WRITE_ADDR(0*32);
for (i = 0; i < 16; i++)
{
r = (pal0Src[i]&0xF00)>>8;
v = (pal0Src[i]&0xF0)>>4;
b = (pal0Src[i]&0xF);
r -= nb0; if (r>0xFF){ r=0; }
v -= nb0; if (r>0xFF){ v=0; }
b -= nb0; if (r>0xFF){ b=0; }
*pw = (r<<8)+(v<<4)+b;
}
}
The important thing to note are the GFXCNTL and GFXDATA pointers.
It's the same with anything. You need to learn things in small steps. You accumulate both experience and knowledge at the same time. Once you 'know' somthing, it's just a matter of working within the programming language and hardware arch. While it does require more knowledge than BASIC, the process is pretty much still the same (at least core logic). If you would have kept at it with BASIC to make games, you probably would have start directly accessing the hardware itself rather then using pre-existing functions like Print or Draw.Quote:
Originally Posted by Yoder
Assembly itself doesn't offer this intermediate step, but it also has nothing to do with those levels of functions. Some one could very well make those equivalent functions for assembly (a library), and you have to do is call them.
Assembler seems daunting, but really it's not. While there are a lot of instructions and lots of logic to use (processor state flags), you're not require to learn and understand ALL of it before you start coding. You just need to understand a few basic but essential instructions and logic. Load/store/cmp/arithmetic and some bit logic (shifting/rolling/anding/oring/xoring/bit testing). The instructions in and of themselves are simple. Anyone can learn that part. But like all programming languages (and BASIC included), you have to learn to build more advance logic/structure/operations using these lesser components. One reason assembly looks daunting because it requires more code than higher level languages, so it someone who's not directly familiar with it - will think it looks 'complicated'. It CAN be complicated just like C or BASIC or any high level language can be too, but it can also be simplistic in code too. If you're not familiar with it, it looks all the same to you. I'll not lie, advance coders often write advance code - exploiting logic or instructions or some such.
As far as accessing the graphics hardware, Genesis doesn't have a 'bitmap' system like a lot of old home computers (or had you believe). It's actually much easier to do game stuff on the Genesis. Moving an object around on screen is as simple as giving the X/Y coords, the size of the sprite (in 8x8 chunks), the pattern #, the palette #, and the x/y flipping options. Once you get it set, all you have to do is update the X/Y coords per frame to move it around. The Genesis isn't made for bitmap 'pixel plotting', so if you have a game in mind that needs that - it's going to be more complicated and limiting to pull off because it doesn't have that setup.
The other part is where to get started. There is more than one assembler. Some require linkers, some don't. If you want to look at example code, and you're just starting off, it's important to have that piece of code be compatible and assemble on the assembler you're using. This probably scares first time assembly learners away. The 68k syntax is pretty much universal from what I've seen, it's more of the directives and their functionality that are different. I used snasm68k when I first started on the Genesis, because the demo code I was looking at was to be assembled with it. But I've since moved on to something that's a little more flexible for what I want to do.
The second part is to have a debugger. If you're just learning assembly for a processor, for the first time - it's best to have an emulator that you can step through. It doesn't have to be a Genesis emulator. It can be a standalone 68k emulator. The idea is that you get to see what the instructions that YOU wrote are doing, line by line (and see how things like registers/flags/PC/etc changes as each instruction executes). If you're done assembly for another processor before, then it's not really that important - but it couldn't hurt.
The 'art' or skill comes from when you start approach the system's resource limit. So you design ways to push ahead but at the same time not exceeding this limit. Be it rom space, ram space, speed, or graphic/sound related. By using exploits in logic (cpu for speed, or graphics for display), compression (save on ram or rom), dynamic systems (usually ram), and other clever trickery (the accumulation of more than one).Quote:
where you're writing low-level code and directly interfacing with the CPU and RAM is an extremely advanced "art".
Exactly what i missed when i joined this forum. I just started a topic today that should have been placed in the new development section, The title is "Getting the genesis online". Maybe it should be moved there but i think an admin is needed for that.
Great name too, it fit's perfectly.
Kamahl and Tomaitheous, thank you for your description. That was helpful in a number of ways. That's interesting that the Pier Solar code is in C. I can recognize the control structures and bit-wise operators there, but I guess the rest are function calls that access the hardware layer directly. That's where things get funky when you're used to programming for the windows API, Java libraries, or now the .NET arch...
It's gotta be exciting seeing your code running on a console you grew up with!