So, I got an idea. Anyone can make a pac-man clone. They are easy. But then I saw a video here. They explain that at the time they had a limited amount of memory to work with. They had to fit an arcade game on a home console cartridge. So I thought. Some people find the 4k hard. What if someone tried to make a game on the limits that atari cartridges had at the time? I think it would be a cool challenge, assuming it is possible... Granted, it's probably harder to do since you have to limit the graphics as well as processing. I want to try this though. If it is possible, how do I do it?

EDIT:Also, what were they limited to specifically? Like, how much ram? How many megabytes?ANOTHER EDIT:After some googling, I found this document: http://nocash.emubase.de/2k6specs.htmIt explains that atari was:CPU: 8 bit 1.19MHzRam: 128 BytesResolution: 160x192Pallette: 128 colors (NTSC), 104 colors (PAL), 8 colors (SECAM)

I have no idea what halve of these things mean, but I get the ram. So I could do some benchmarking to see if java alone takes up >=128. If so, this project is impossible. 160x192 will be an easy thing to do. Just scale down the graphics. As for the cpu, I never got what MHz means. So I googled it and found it is the number of cycles a proccesser does in a second. so it does 1,190,000 cycles in a second. Wow, for the 80's. I expected more 780,000-ish. The pallette, I have no idea what NTSC, PAL, or SECAM means. I googled, and saw that NTSC is just a television used a lot. So I can assume that the rest are too. So just to list off, to meet the challenge, the game must:- Be a game- Have 8-128 Colors- Be 160x192- Take up 128 bytes of ram(I would have the megahertz thing, but that would mean I need a system with that many megahertz...)Well, benchmark time!

Okay. So I should just look up the storage on those cartridges? And also, I am limiting graphics + proccessing not to use less storage, but to simulate how it would feel to have so little processing and graphics power to work with at the time!

If you're aiming at 128 bytes of RAM (which I'm unsure whether that really was the case in the atari... that would mean you almost couldn't write any code, since code will take up 128 bytes quickly...)

Anyways. It's pretty much impossible to do in java, but why not make it a little challenge with a little bit of learning and understanding of how the pc works?

Maybe overkill, maybe not your level, but you could try to write a little atari CPU simulator and write a little bit of code in assembler. That's what they did back then.

You misses that I said I would subtract what jvm took up from my final ram usage. So, I could write code. Just can't find software to measure ram. WAIT! Ctrl Alt Delete solves everything! (Task manager). Granted, my measurements are likely completely off, but it will still be a fun challenge!

Only took up 8,000 -11,000 K Memory!Assuming K means Kilobytes, java alone at its simplest loop uses8,000,000 - 11,000,000 Bytes of ram. This will take no time at all! I only am at a 7,999,872 - 10,999,872 byte margin of error!If you didn't catch the sarcasm, I think that I need to switch to c++ or something for this... Oh the dreaded c++ (for me anyways...).

I'm worried I'll fall in love with c++, and never go back to java.

EDIT:So far, c++ is very mean! Come on! I just got it to work, and there is a huge learning curve! I know the syntax and all, just not how to make something appear on a screen. GER!

I have not coded in an atari but I have made console stuff (gba and ds). Even c++( the stdib stuff) is considered wastefull.

You cannot really compare how you code on the pc and on a console. Consoles usually have dedicated hardware for gfx, sound, etc that you can directly manipulate through direct registry writes. They also have vrams you could directly manipulate ( so the ram part in the console is not your limit ) where you store your runtime gfx.

The cartridges can also have extra memory for storage.

Case in point. The ds has only 4mb for data and storage with 256 kb( forgot if it's 512 ) of vram for all your tiles, 3d and bg, but you can write data on that vram at runtime from nitrofs(ds file system). You cant do that on the pc with modern os. You'd need to use a HAL.

If you want to code in retro consoles, learn and use what most people use. As they say, "When in Rome...".

I work developing embedded software, and, since development is done on more powerful PCs, we have to enforce memory/data size limitations on our own, so I'd say it isn't a bad exercise to learn how much you can do with very little.

To get as close as possible without needing to resort to lower level shenanigans, you could always try and implement a sort of memory and data pool infrastructure, similar to how thread pools are handled.

Just define the size limits of said pools, and have your program request all memory from them, rather than instantiate them directly.

A simple example would be to extend an storage class, for example a List, to include a byte capacity counter, so you're limited on the amount of data stored into memory. I've used something similar myself.

Also, what's the huge problem with C++ and making something appear on the screen? Do you mean making a GUI is tough? Or do you mean that the console is closing because you're not running from the command line and you don't call system("pause");? I have no trouble with C++ so I'm confused what's the huge problem that makes you want to destroy your computer. Also, if C++ makes you want to destroy your computer, then Assembly is going to have your computer in pieces within minutes.

Also, what's so bad about if you worked with C++ and started to like it the most? You have no obligation to any language. I've worked with C and C++ (among many other languages) after Java, and Java is still my favorite by a lot.

Opengl. I recall a quote from a book I read on it:"The only reason that every programmer doesn't find out how to use opengl easily, is because the masters of it won't teach for free, and initializing is difficult..."Not to mention that every tutorial I see uses a different IDE. Also, it's been a bit. But I remember hearing that java is productive, and c++ is effective. IDK. Every time I try c++ I fail, since I NEED opengl. Why can't it be as easy as lwjgl?!

Even though developing for Windows is tough, I have managed to get an OpenGL 3D First-Person camera without head turning on Windows (haven't ever grabbed the source from my Windows drive onto Linux) because I couldn't find a good tutorial for the trigonometry set up. If need be, I could grab the source code and send it your way. I suggest you start with GLUT, then maybe work your way to SDL. GLUT allows for more pure OpenGL programming, similar to LWJGL. Getting Code::Blocks would be best if you need an IDE (I do not like IDEs for the most part because they tend to keep the Makefile or build.xml used hidden), as it can install MinGW (good compiler) with it and you can click New > GLUT Project I think. You might need to do some more tinkering, but I used Code::Blocks when I made my 3D First Person OpenGL thing with GLUT.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org