So far, I have some code written for updating rows of the nametable, and writing it to the PPU, so that's all there's a screenshot of. It should be doing 4-way scrolling later. I don't have the code for assigning the attribute tables in yet, so it's all palette #0, the gray palette.
It will be an adventure game on a bunch of large sprawling maps, and it's targeting the minigame size of 16k + 8k CHR ROM.
Giant 8x8 metatiles (of 16x16 tiles) and RLE for picking the metatiles will makes things really big at a really small size. Hope you don't mind repetition
Really nice! This is in the Minigame category? Oh snap....I'll never win crap from any compo but what the heck it'll be fun
Let there be color!
Got the attribute tables working. Bugs in the interim version of FCEUX misled me to believe there were strange bugs in my code.
Now to test the attribute tables code for drawing column-by-column instead of row-by-row. (edit: done, column-by-column updates fine too)
Then later...scrolling!
Dwedit wrote:
Nice
reverse squiggly blocks. Do you plan on having screens with the other Tetris blocks on them?
And now it scrolls freely in 4 directions, and I managed to squash LOTS and lots of bugs in the process.
Play with the scroller demo
That looks pretty neat and a good start. I assume that you work on scrolling first before adding a sprite character and collision detection?
I don't know since I haven't made a game before.
When I did Chu Chu Rocket, the first thing programmed for the NES was the code that moves the mice forward. (basically moving an array forward in memory), but there was tons of planning before anything got written, mostly to figure out how to animate all possibilities of moving mice with a limit of 512 tiles.
For this game, I wrote the background rendering and scrolling system first. Now when I make the game logic, I just change the camera coordinates, call a function, and it scrolls somewhere else, and the new rows and columns get drawn at the next NMI. It will screw up if it tries to scroll more than 8 pixels though.
Also, long before I wrote any NES code for this game, I made this thing:
Still unfinished, no sprites there either.
.
Gotta love how this is the first time I ever use DirectDraw, then Microsoft goes and deprecates it several years ago.
That's interesting how you're designing this game. Let me know how it turns out. Also, are you planning on adding a music driver?
Looks very interesting. What tools/assembler/SDK are you using for creating of the game? Are you going to release the sourcecode? Do you plan to use some kind of compression (For the graphic tiles it will work very good) or you will put the raw data in the ROM?
16KB shall be enough, but if you compress everything, you will have much more free space for Title Screens, Intro, Tutorial, Manual and most importantly - Music.
For the minigame competition, compression for graphic tiles would actually reduce the amount of space for everything else because the rules give you a "free" 8 KiB CHR ROM, and CHR ROM can't be compressed.
(Full disclosure: There is one situation in which this might not be the case, involving a game that only uses half its PRG ROM. A game with a 9 KiB PRG and a 10 KiB CHR that compresses to 7 KiB would work better with CHR RAM. Concentration Room might have been like this at one point in its conception.)
Using ASM6 to build the game. Using YY-CHR and Photoimpact to do the graphics. Using various other custom tools as needed.
Unless Jeoren changes the rules, I can use 8KB of CHR-ROM with any graphics in addition to the 16k of PRG ROM, no data allowed in CHR-ROM, and I can NOT use an 8k WRAM chip.
With CHR-ROM being static, I won't use any graphics compression.
Level data will be compressed to hell.
Dwedit wrote:
Level data will be compressed to hell.
Try to compress the data in a "block X spans an area of Y by Z blocks".
The kind of compression I'm using:
Big 8x8 blocks of 16x16 tiles, then the map that uses them is RLE compressed. Each 8x8 block is 4 bits per tile, for 32 bytes per block, packed but not compressed, so there's random access to the tiles. 256 of those would be 8K in size.
I was also thinking of possibly compressing the blocks instead of just packing them, would need some RAM to hold the decompressed blocks, I have 768 bytes that I haven't reserved yet, so that could be 24 blocks per area. In order to have any benefit, the blocks would need to be significantly less than 32 bytes each.
With enemies placed on the map now. They don't do anything yet.
Black bar on left is a crude CPU usage counter that turns off sprites and backgrounds for the left 8 pixels before calling WaitFrame.
Dwedit wrote:
With enemies placed on the map now. They don't do anything yet.
Black bar on left is a crude CPU usage counter that turns off sprites and backgrounds for the left 8 pixels before calling WaitFrame.
SO. PRETTY.
Wow this really makes me want to do a game with different screens so I can make pretty graphics, too!
Dang man.....this looks like RetroUSB future stock, hopefully!
Looks fairly cool ! The monster looks copied from Crystalis though.
Quote:
Dang man.....this looks like RetroUSB future stock, hopefully!
Hopefully not... I want ROMs to be released to the public domain.
Bregalad wrote:
Looks fairly cool ! The monster looks copied from Crystalis though.
Quote:
Dang man.....this looks like RetroUSB future stock, hopefully!
Hopefully not... I want ROMs to be released to the public domain.
Meh, the bit of money that would come with it would just make more sense to make a new game and then work harder on both, so I'd like that, but PD would be good to....wait, this is going to be a NROM game, right?
Bregalad wrote:
Quote:
Dang man.....this looks like RetroUSB future stock, hopefully!
Hopefully not... I want ROMs to be released to the public domain.
If you have an idea for a game that won't fit on the NES due to
hardware limitations and won't fit on a PC due to the lack of home theater PCs (that is, PCs connected to a TV-sized monitor) among non-geeks, you have to make it for a modern console, and there are
two requirements for that. One is leasing office space, and the other is "game industry experience". I don't think a game on your CV counts as "game
industry experience" unless you've been paid.
But then NROM games like the ones for this compo aren't the sort of things that sell themselves alone.
Actually all you need is an xbox 360, a 100 bucks and ALOOOOOOOOOOOOT of free time....
Jeroen wrote:
Actually all you need is an xbox 360, a 100 bucks and ALOOOOOOOOOOOOT of free time....
I got XNA at one point, but you also need DX11 and Pixel Shader 3.0! -cries-
Back on topic, are the enemies just placed there to look good or do you have the engine doing it dynamically yet?
Quote:
I don't think a game on your CV counts as "game industry experience" unless you've been paid.
Interesting point. But if you get to the point that sombody consider to hire you in the video-game industry, you can give a link to your potential employer so that it can play your game, it will definitely be a HIGH plus for you. I don't think this will ever be happening to any of us, but it it were to happen to me, I'd be glad to show off that I made a game or even just a game engine, all from scratch. Not many people could claim this I guess.
Bregalad wrote:
But if you get to the point that sombody consider to hire you in the video-game industry, you can give a link to your potential employer so that it can play your game, it will definitely be a HIGH plus for you.
That's why Battle Kid: Fortress of Peril has a demo. An animator's demo reel doesn't have a full feature film.
Quote:
it it were to happen to me, I'd be glad to show off that I made a game or even just a game engine, all from scratch.
The console makers demand more. If you want to get a devkit so that you can get onto a console's download store, you have to show that you are capable of making something that people want to
buy, not just play for two minutes and go on to the next
steaming pile of tech demo.
Jeroen: XNA has
known limitations that make it suitable only for "little toy games", as
a Slashdot user put it. It also needs a PC made in the past four years or so with Windows and a discrete video card, and I don't have that.
Samurai dead dish washer was made with xna. It's far from a little toy's game. Yes it's not gears of war or halo in terms of technical achievement but you can make fun and GOOD games with xna, and most importantly on modern consoles. Also I think having to have a modern pc is a far better option then having to spend several thousands on actual licenses no? I AM aware of the limitations...but I do think that as an indie studio you can make a decent game with it, for cheap.
Sorry about this. XD But what does 360 use for graphics? Isn't it standard DirectX with some C++/C? Why not just do it on PC in the first place since it's nearly the same.....I mean, yeah, XNA has a forum with help and info on it and making PC games has nearly no info on it (Unless you have CA$H) but from searching, is there any real way to do games on PC easily with well documented programs? Allegro seems okay, but I can't find any info on it.
I did a bad thing hijacking this topic my bad....but I actually do really want to hear more about the game. XD
Eh, after hearing about XNA not allowing any creativity with the sound at all, I knew there was no way I would ever want to use it. I thought "indie" was short for independent, and it sounds to me like Microsoft is turning the definition on it's head, seems like anyone developing under their system would be very much dependent on Microsoft with their forced standards and rules. I didn't know that they even get to choose what words you can and cannot use in your game, what kind of independence is that?
Sorry for off-topic post, Dwedit your game looks pretty cool from the screens.
Note i'm not actually defending the platform here. I'm just saying that Tepple's notion of it being impossible to get a good game without all kinds of licenses is far from truth.
Yeah sorry if I sounded harsh, it is a valid point, but XNA still sounds like too much vendor lock-in. Just looking it up quickly I see that everything has to be in C#, not C/C++/anything else. So you also have to use a Microsoft-designed language, it seems they basically "own" your game in a sense. Maybe there is a C to C# compiler though.
65024U: I forgot to mention too, look into SDL and that tutorial I posted in the other thread. Allegro probably is mentioned more because it's been around for longer, I remember a lot of emulators in DOS and other stuff used it. SDL must be more recent but it is used a lot, and well-documented. It's not as easy as NES development though, overall (IMO).
65024U wrote:
Sorry about this. XD But what does 360 use for graphics? Isn't it standard DirectX with some C++/C?
XNA on the Xbox 360 uses an API reportedly similar to Direct3D. However, you can't use C or standard C++; instead, you have to use C# or a language called "C++/CLI with /clr:safe" that's C# with C++-style syntax. You can't take your existing C++ codebase and make a new XNA front-end for it because standard C++ and C++/CLI with /clr:safe are not compatible languages. In addition, you can't use DirectSound; instead, you have to use XACT and lose the ability to synthesize audio at runtime. To break these limitations, you need an office and a commercial game on your CV.
Quote:
Why not just do it on PC in the first place
Because most of your audience has their PC connected to a monitor far smaller than a living room television, and it's hard to fit four people around such a monitor.
Quote:
is there any real way to do games on PC easily with well documented programs? Allegro seems okay, but I can't find any info on it.
SDL and Allegro are the popular libraries for native development that's cross-platform among Windows, Linux, and Mac OS X. Both let you use OpenGL for graphics if needed.
And I agree it was a hijack, but I'll forgive and forget if you let me know at which point you want the topic split.
Yeah IDK I'm fine depends on what you guys talk about....
Do the trees and the grass use the same pallet just takes advantage of the 3rd color the grass doesn't use for the tree limbs? I'm being serious with this question.....because it looks dang sexy. XD
Bregalad wrote:
(...) The monster looks copied from Crystalis though. (...)
Aye, be careful there Dwedit, it could affect your reputation. Besides, mixing several pixel art styles doesn't work well (monsters from Crystalis, water from FF1, ..)
No offense intended, just being a nerd that is a fan of originality.
I'm just using ripped graphics temporarily until they can be replaced. Right now the ripped graphics includes trees from FF4, the hero from Chronicle of Radia, monsters from Crystalis, and some dungeon tiles from FF3.
If it's all ripped, then what's the point of showing us screenshots? At least show us a video, or something that actually displays the work you've done.