Classic games ...... can we make game like that?
I may be mistaken here but isnt it as follows with NES:
A Kernel is loaded onto the system which handles all API relevant stuff, therefore if you say a rom is so and so big, thats only the arts, music and the core game stuff. Thus you have to compare the rom with a games executable without DirectX or OpenGL.
-CProgrammer
A Kernel is loaded onto the system which handles all API relevant stuff, therefore if you say a rom is so and so big, thats only the arts, music and the core game stuff. Thus you have to compare the rom with a games executable without DirectX or OpenGL.
-CProgrammer
from what i''ve seen there two different sizes: the file size and the cart size. i''ve was quoting from the cart size, which is the bigger of the two.
quote:Original post by CProgrammer
I may be mistaken here but isnt it as follows with NES:
A Kernel is loaded onto the system which handles all API relevant stuff, therefore if you say a rom is so and so big, thats only the arts, music and the core game stuff. Thus you have to compare the rom with a games executable without DirectX or OpenGL.
-CProgrammer
DirectX and OpenGl aren''t part of your game, only API calls (well, mostly).
Yes you can make games small. There was a little contest on the java boards. It was called 4k game contest. Rules were do whatever you want, but it must be playable, not a demo, and it must be under or equal 4kB.
First optimization was: removal of main method. It saves 12 bytes. Others were drastic as well.
There is a minimal amount of memory that is needed for a complex game. SNES games were example of potentially excellent games that have problems with low memory, and persistence of the world.
Macro assembly is also an option if you''d like to have small EXECUTABLE files. Compression could be high, but it wont alow you do 1200 x 1024 CT like graphic under 3 kB.
First optimization was: removal of main method. It saves 12 bytes. Others were drastic as well.
There is a minimal amount of memory that is needed for a complex game. SNES games were example of potentially excellent games that have problems with low memory, and persistence of the world.
Macro assembly is also an option if you''d like to have small EXECUTABLE files. Compression could be high, but it wont alow you do 1200 x 1024 CT like graphic under 3 kB.
since my expertise is NES emulation, I shall reply to you as well as I can.
Firstly, you have to take code size into consideration. The NES uses an m6502 and for the most part instructions were 8 bits followed by data if needed. addressing is 16-bit.
this could potentially mean that the code to do one thing on the NES would be roughly half the size of the same code to do that on a PC...plus, add in to the equation that the NES was a very specific piece of hardware to do a very specific thing, and that for instance code to poll the joysticks on the NES is analagous to code to completely setup and map input on varying hardware on the PC. so you see, code could be simpler in many ways.
now on to graphics. graphics were generally at their highest resolution 4-bit color. It''s been a few months since I tinkered under my emulation code, but I remember backgrounds being essentially 2-bit. Morever it was all tiled...so basically, NES games had small code and smaller graphics.
the price of progress is bloat. if you want to make a classic at that size, crack open a tutorial on M6502 assembly and get into some NES programming.
alternately - use vector graphics for everything.
my 2 cents.
Firstly, you have to take code size into consideration. The NES uses an m6502 and for the most part instructions were 8 bits followed by data if needed. addressing is 16-bit.
this could potentially mean that the code to do one thing on the NES would be roughly half the size of the same code to do that on a PC...plus, add in to the equation that the NES was a very specific piece of hardware to do a very specific thing, and that for instance code to poll the joysticks on the NES is analagous to code to completely setup and map input on varying hardware on the PC. so you see, code could be simpler in many ways.
now on to graphics. graphics were generally at their highest resolution 4-bit color. It''s been a few months since I tinkered under my emulation code, but I remember backgrounds being essentially 2-bit. Morever it was all tiled...so basically, NES games had small code and smaller graphics.
the price of progress is bloat. if you want to make a classic at that size, crack open a tutorial on M6502 assembly and get into some NES programming.
alternately - use vector graphics for everything.
my 2 cents.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement