GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Making a game system Page 1, 2  Next
View previous topic :: View next topic  
Author Message
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Wed Feb 03, 2016 8:01 am    Post subject: Development Log - Making a game system Reply with quote

First of all: hi again! I've been a long time lurker, but some of you might even remember me.

Like everyone here I have been a long time into making games. I have actually coded more game engines and applications than games themselves though. But this time I am wrapping all of it into a much more ambitious project. And I thought it would be a good idea to create a log and share it with you guys :)


SO, WHAT IS ALL THIS ABOUT?

I am a big fan of old consoles and arcade systems. And I'm not the only one: Nowadays there are retro fans still programming games for the NES, SNES, Genesis... often even in assembler! There is also a big indy game movement with a lot of retro games imitating 8 or 16bit machines.

There were also attempts to create new retro HARDWARE. The Ouya, the Coleco Chameleon, Retro VGS, etc. tried or actually did physical releases of their consoles. And they were all utter failures because of price, poor decisions on business/design, and barriers of entry for potential developers.


WHAT WILL I DO INSTEAD?

I believe that today it is feasible to create a FULLY VIRTUAL console. If I can decide how it works, design its hardware features, its architecture... and release a full specification, then that specification will, in fact, BE the console. Games will be compiled into roms and I will program a full emulator to run them, so there is no need for any physical releases.

There is of course another necessary part for this project to be successful, which is getting other people to make games for the system. Making it easy for game creators is a big priority. So, along with the emulator I will create a small IDE, so that games can be programmed in C. And it will integrate small tools to import images, sound samples and music from common formats into the roms.

Finally, to make the process accesible, I will release a set of documentation and I will be making some small roms as well, demonstrating commonly used features of this console (such as: scrolling, playing music, moving the player, etc... ).


WHAT ARE THE ADVANTAGES OF A SYSTEM LIKE THIS?

(1) Convenience for players! Like in emulators, games are just single-file roms. No installs, no incompatibilities. Not even the emulator has need to be installed, just unzip and load a rom. Nobody needs gaming platforms or accounts of any kind, or internet connection.

(2) Convenience for developers! No need to test games under different PC configurations. No unicode or internationalization. No licensing. No need to learn game engines. Direct, easy access to hardware features such as joysticks. Also they can have retro style games while still having a machine with more power and features than classic consoles and arcades (a kind of "next-gen 2D console", if you will). But still within low development times and costs compared to more modern PC games.


LAST WORDS

Expect this project to be complex and take a long time to be complete. Still, I will try to post regular updates here. In exchange I invoke the right to ocasionally summon GDR wisemen for opinion and help ;) Speaking of which: I will be releasing documents and files in this thread, covering the whole process. Anything from PDFs, code samples, tests... but I have no idea where to upload it to share it in the forum. Help anyone?

Many more details to follow shortly.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1609
Location: Your consciousness.
PostPosted: Sat Feb 06, 2016 6:58 am    Post subject: Reply with quote

You are correct. That IS a fucking ambitious plan/project! :D

For uploading and sharing files, dropbox or google docs, google drive come to mind. You could also just host them in a free git repo provider like github or gitlab.

You might also want to take a peak at Pico8 which is a virtual console in alpha stage but already has tons of software/games available for it.

Are you going to design actual hardware schematics and then write an emulator or are you writing a virtual machine with a limited feature set that mimics the features of oldschool hardware?
_________________
0xDB
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Sun Feb 07, 2016 11:33 am    Post subject: Reply with quote

Hardware schematics seem to me like going a bit too far, since what you will actually need is only to define how the hardware has to behave. You will be having some binary programs, and the possible interpreters for it (be them hardware or software) must comply with that behavior. Further detail could be considered "implementation dependent", or in prettier words, you give some freedom to potential implementors ;). I do believe however that some basic architecture and component diagrams may be needed.

I didn't know about the Pico8, but it seems very interesting. I especially like that their official web acts as a "hub" that gathers all the roms made by different people. But it seems to me more like a "toy computer" (having even a Lua console) than a console for which we are going to see real games.

Just to give a rough idea, these are the broad specs I am thinking about at the moment:

VIDEO:
----------
- Resolution: 640x360 pixels (16:9; scales exactly to 720p at 2x, to 1080p at 3x and to 1440 at 4x)
- Video chip provides sprites and scroll layers (tile maps)
- Output is true color, but all graphic assets are based on 16-color palletes
- Up to 16 palettes for sprites, and other 16 for backgrounds (total maximum of 512 colors on screen)
- Both sprites and backgrounds support rotation, zoom and transparency effects
- Video output works at a constant 60 frames per second

AUDIO:
----------
- Output at 44100Hz, 16-bit, stereo
- All audio is based on programmable samplers: sound samples can be looped and altered in volume, pitch and panning
- There are 16 channels for music and 8 channels for sound effects
- Music is closely based on tracker music, in fact it will be possible to import MOD, S3M, XM and IT files

CPU & ARCHITECTURE:
-----------------------------
- CPU will be 32bit and work at 25 MHz. Supports floating point operations
- CPU can execute instructions directly from cartridge (mapped to RAM)
- CPU is my biggest unknown so far, so I can't give much more detail!
- Audio & video chips, however, may need to load their assets into their internal memory
- The main timing system will be per-frame (internal frame counter)

OTHERS:
-------------
- The console has 4 gamepad ports, each gamepad has a digital D-pad and 6 buttons + start (no select :P)
- The console supports swappable memory cards for saved games
- No other input or output is planned (no mouse, no internet connection, no hardware extensibility)
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10583
Location: Canadia
PostPosted: Sun Feb 07, 2016 11:46 pm    Post subject: Reply with quote

A popular project that sounds similar to what you're planning.

http://www.lexaloffle.com/pico-8.php

EDIT: Ahh, I see I wasn't the first to mention it.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Mon Feb 08, 2016 3:45 am    Post subject: Reply with quote

Don't worry PoV ;)

Pico8 actually looks great for hobby projects, and though I can understand the reasons, it's a shame that they went for such a low spec. Pico8 has less resolution than the original GameBoy, and can put barely more colors on screen. The sound chip is also pretty retro.

My aim instead is to create something that overpowers classic consoles and arcade boards in all aspects, while still working on similar principles. I haven't so far been able to tell if Pico8 uses hardware sprites and scroll planes, but seeing that there is some 3D polygon demo, it's likely that it doesn't.
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Mon Feb 08, 2016 5:51 am    Post subject: Reply with quote

By the way I am having trouble finding out if pico-8 is actually free or not. Apparently you can only use Pico-8 for free on their website, otherwise you need to buy their game Voxatron to get Pico-8 ant its tools. Definitely not the approach I am taking (which is making all the project open source).

I have also found this very interesting thread which mentions a couple of similar projects. One of them is PuzzeScript, apparently browser based and with the same minimalistic approach.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1609
Location: Your consciousness.
PostPosted: Mon Feb 08, 2016 7:09 am    Post subject: Reply with quote

Arne's Famicube project also looks highly inspirational and is somewhere between 8 and 16bit consoles, not as crippling as NES restrictions but also not as totally almost unrestricted as an A1200. Pure design pr0n.
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10583
Location: Canadia
PostPosted: Mon Feb 08, 2016 12:53 pm    Post subject: Reply with quote

From what I understand, Pico-8 is available standalone. It can also sometimes be had for free (the developer sometimes offers free licenses to game Jammers).

Okay, with that out of the way, here's some thoughts.

Quote:
(1) Convenience for players! Like in emulators, games are just single-file roms. No installs, no incompatibilities. Not even the emulator has need to be installed, just unzip and load a rom. Nobody needs gaming platforms or accounts of any kind, or internet connection.

I just want to point out that the most convenient way to share a game today is with a URL. If you can click a URL and start playing the game immediately (in the browser), then that's a win.

Quote:
(2) Convenience for developers! No need to test games under different PC configurations. No unicode or internationalization. No licensing. No need to learn game engines. Direct, easy access to hardware features such as joysticks. Also they can have retro style games while still having a machine with more power and features than classic consoles and arcades (a kind of "next-gen 2D console", if you will). But still within low development times and costs compared to more modern PC games.

Most people actually find "game engines" (or Middleware as we call it these days) easier than hardware access. Low level hardware access is an old idea that's really only interesting to engineering types, but even then high level libraries like SDL simplify this across a variety of platforms.

Quote:
Just to give a rough idea, these are the broad specs I am thinking about at the moment:

From a pure specs perspective, you've basically described the original PlayStation. Even the 16 color palettes you speak of, using small 16 color sprites was a very effective way to push more performance out of the system (there was a small cache about large enough for a 24x24 pixel 16 color sprite, and you could tint it with palettes).

Other specs sound exactly like the GameBoy Advance.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Mon Feb 08, 2016 2:20 pm    Post subject: Reply with quote

PoV, I totally see where you are going. I have to say I am perfectly aware that what I'm proposing may be not needed, not relevant or not wanted. And you do well to give me some critisism.

Of course, I (or other people) could just go and try programming new games for PSX, or Gameboy Advance. Or other classic consoles. I do however see some big problems with that:

- First, the resolution of any old console is just ridiculously low by any of todays standards. What I am proposing has 3 times the pixels of PSX, and 6 times that of GBA. Plus, no distortion since it is 16:9.
- Second, programming games for old consoles is damn hard! And not just hard because of the limitations themselves (palettes, etc). In fact, many people voluntarily restrict ther projects to those limitations. But even if new tools allow you to not program in assembler and use C, the barrier of entry is way too high. You have to read lots of tutorials, know many tools, use very specific formats... Not very attractive. In that sense, projects like Pico-8 do so much better.
- Even the PSX was not exactly a powerhouse when it came to 2D. There are very nice 2D games: Alundra, etc. But it struggled with mere conversions from NeoGeo (Saturn did better, though).

Regarding online play, I wasn't surprised to read you suggest that. I personally love collecting my roms, and I would hate to be required an internet connection to play my emulators! Also I am a desktop programmer, so even if it seemed a good idea to me I wouldn't be able to accomplish something as complex as this in HTML, or set a server for it. And as for smartphones, I have never really cared about them save for a couple of apps.
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10583
Location: Canadia
PostPosted: Mon Feb 08, 2016 3:34 pm    Post subject: Reply with quote

Making something because you want to make something is totally fine. But having actually been there/done that, I thought I'd share my 2 cents. :)

carra wrote:
- First, the resolution of any old console is just ridiculously low by any of todays standards. What I am proposing has 3 times the pixels of PSX

You might be surprised to hear that PlayStation was able to do 640x480. The problem is you only had 1 MB of VRAM, and you had to also fit your frame buffer(s) in there. Unfortunately, you can't fit two 640x480 sized screens at 16 bits per pixel in 1 MB. Also, moving data from RAM to VRAM was slow (or rather VRAM->VRAM was faster, and if you kept your data under a certain number of bytes and repeated it, it was even faster).

Anyway, my point is that this was a 33 MHz machine, and you're spec'ing 20 MHz. I'm just thinking you're underestimating your figures.

Quote:
- Second, programming games for old consoles is damn hard! And not just hard because of the limitations themselves (palettes, etc). In fact, many people voluntarily restrict ther projects to those limitations. But even if new tools allow you to not program in assembler and use C, the barrier of entry is way too high. You have to read lots of tutorials, know many tools, use very specific formats... Not very attractive. In that sense, projects like Pico-8 do so much better.

Yes, consoles are hard. I just don't really think there's a need for a half-way point. If you want the challenge, you'll challenge yourself to code for a console. If you want development to be easier, you'll use a tool that's easier. Things like GameMaker and Construct 2 seem popular among non-coders. The middle ground is learning the native APIs of a platform.

What Pico-8 also does is it has integrated tools for making assets, even audio. It's a complete environment, like a game engine, but a bit more flexible.

Middleware is good, great even.

I just think it's better to spec something like this out with what it can do, rather than what it can't do.

It's things like the clock rate, the fixed number of palettes, fixed number of audio channels, these sort of details just aren't important anymore.

Tool limitations, those are fine. If you can make a better user experience for a 32x32 sprite editor than a flexible one, go for it. It's just not worth adding arbitrary system restrictions if they don't help you.

Quote:
- Even the PSX was not exactly a powerhouse when it came to 2D. There are very nice 2D games: Alundra, etc. But it struggled with mere conversions from NeoGeo (Saturn did better, though).

The PSX shouldn't have struggled with NeoGeo ports. Even though the GBA was newer, the GPU on the PSX worked so much better. We did have more CPU headroom working on the GBA, but working on the PSX was soooo much nicer. I would fault the developers of any NeoGeo ports for not knowing how to use it properly.

The Saturn was weird. All it could do is use Quads. At least the PlayStation was sensible, and let you use Triangles or draw lines. :D

Quote:
Regarding online play, I wasn't surprised to read you suggest that. I personally love collecting my roms, and I would hate to be required an internet connection to play my emulators! Also I am a desktop programmer, so even if it seemed a good idea to me I wouldn't be able to accomplish something as complex as this in HTML, or set a server for it. And as for smartphones, I have never really cared about them save for a couple of apps.

I just wanted to help you realize that your criticism of development isn't a common criticism. The Retro VCS was crazy. It's like it was designed within a bubble. As if 20 years of game development didn't happen, as if we learned nothing. It's baffling that machine.

Classic game machines weren't designed by picking and choosing what sounded cool. These were either off-the-shelf parts, like the CPUs, the memory, and sometimes custom hardware like the GPUs. You didn't always know what people could and would do with your GPU, so they just had to make them, and see what happened. Then they made a better one, and a better one.

Old computers had character maps. Eventually some hardware designer added pixel offset registers to those character maps, and clever people realized they could use that to do neat on-screen visuals. Then they added alpha colors, and multiple character maps. Then they added sprites, and every other little feature that made sense. Eventually we reached a plateau, where rasterization made sense. We could add custom hardware that did shaped copies of VRAM. Eventually we added transforms to that. And then lo and behold, we had the modern graphics chip.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Tue Feb 09, 2016 1:00 am    Post subject: Reply with quote

Wow, you sure do have a lot to object against this!

Maybe I have not focused this project correctly.
I'll try instead to show you the WHY instead of the WHAT. I'll share what has been in my mind.

***

First of all: Having a well defined binary compatibility is the CENTRAL POINT of what I am trying to achive. Without it, you still depend on the particular HW & SW configurations of each individual user. Without it any game that you write today may be unrunnable some years from now, as would be most PC software save for things such as DosBox (virtualizing a whole computer system to play an old game! overkill, anyone?).

Using game libraries to write your games not only DOESN't solve this, but actually AMPLIFIES these problems: they not only add further layers of dependencies, but also often require specific versions of Windows, of DirectX, of OpenGL extensions, ...

With this said, let's do a mental experiment. If I were to call this project "a standard", instead of "a console", would it feel better to you? Putting it as console may be misleading anyway: this has no intention to ever become a physical machine. A good example of a standard (even if still tied to physical machines) was the MSX. Many manufacturers made their own versions, but all of them shared binary compatibility.

***

Now, in order to see other types of problems, let me remind what has been happening in the 2D programming world...

Development of simple games is becoming ever more of a chore. I was there when you could directly access VRAM and the Sound blaster chip. Yes, you did need to learn a couple of things about the hardware but you got that "simple and direct" flow that let you see a reward with very few lines of code. Where can you get that now, without first preparing lots of SW layers or boilerplate, or some niche virtual machine?

Then came Windows, and you needed to write lots of lines just to get a window. And you needed to use GDI or DirectX. And you could no longer poll the joystick, but you needed to be "event driven".

Then came the new OpenGL 3, and suddenly your old code no longer worked and you needed another 80 extra lines and shaders to draw the simplest triangle (really...?)

Then of course, nowadays you can resort to game libraries! Lots of them, sometimes even one on top of other. Forcing you to yet more layers of browsing through object hierarchies, doing initializations, learning "Visitors", "GameEntities", and abstractions I don't care about. All of this before you can draw a simple sprite on screen.

Other game making systems are much simpler, even mostly graphical (such as RPGMaker), but you are usually quite more limited, even if you script them. Also I have sadly seen way too many of these games fail to run because XX.dll is not found, or error B00167E happened, or because your graphics card does not support gl_arb_separate_shader_objects. This system is just unreliable and not at all acceptable from an end user.

Even when you DO find libraries you like to work with, good luck not having them stop development and get unsupported by next year (I had this happen more than once).

***

I could go on, but I think you see where this is going...

All this is why I am seeing the need for a project such as this. I am always looking for alternatives, and if I had seen some of them that seemed good enough I could just use it (fantasies are nice, but one has to be practical sometimes). But so far I have seen nothing that solves the problems I spoke about. If I ever find it, I will just use it.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1609
Location: Your consciousness.
PostPosted: Tue Feb 09, 2016 2:35 am    Post subject: Reply with quote

What makes you think your system is not going to suffer from all the same problems and issues that you are describing in that which is already there?

I second the notion that making stuff because of wanting to make it is just fine, no need to get all overly defensive and upset about it. That always looks like you have to convince yourself more than anyone else that you really want to make this thing.

It's understandable to be excited about something and the feeling that others may not share the same excitement or enthusiasm about it can be devastating, even frustrating sometimes. But it's your project and you can do whatever the fuck you want with it. You don't need anyones approval or what you may feel seems like disapproval let you distract in any way.

I don't believe PoV is trying to talk you out of it as you seem to think. I believe he's asking you to be critical of your intentions and motivation, because there ARE feasible alternatives to going down the full NIH ("not invented here") route and making classic looking games is much much easier on modern hardware and using modern environments like Godot, Unity, Construct2, SuperPowers(HTML5/JS) than learning a new virtual machine (which your thing is just going to be, another virtual machine, a new dependency to run things on).

If people want to go retro and use tricks that look like hardware hacks, they can just learn programming for the real target machine and use emulators to run it (Emulators are already ported to most systems, so there's the single dependency people need to run their stuff and to spread it.)

Go ahead and create your stuff man, no one here is trying to say "Don't do it!", we're just sharing experience and point out what you might want to rethink and refine in your concept. It's, I am sure about this, all meant constructive, not destructive. Don't think "argument" or "objection", think "thoughts exchange", don't judge, it will feel better immediately.

Most of us programmer types are probably guilty of having fallen into the "must do everything myself" (NIH, not invented here) trap one or more times, spending years and years of fiddling with our stuff and rarely really finishing anything.

It is perfectly acceptable to enjoy that kind of fiddling while ignoring what the world does and says, just don't expect many people to share your own enthusiasm about your own projects. The world does not appear to work that way.
_________________
0xDB
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Tue Feb 09, 2016 3:45 am    Post subject: Reply with quote

0xDB wrote:
I second the notion that making stuff because of wanting to make it is just fine, no need to get all overly defensive and upset about it.

I'm now puzzled! What made you think I was upset with any of you? O_o. If anything, maybe just disappointed with the current general state of 2D game programming and deployment.

0xDB wrote:
there ARE feasible alternatives to going down the full NIH ("not invented here") route and making classic looking games is much much easier on modern hardware and using modern environments like Godot, Unity, Construct2, SuperPowers(HTML5/JS) than learning a new virtual machine (which your thing is just going to be, another virtual machine, a new dependency to run things on).

Which alternative there is? Invoking NIH syndrome is fine when there are, in fact, alternatives, but how do the ones you listed solve what I wrote above? A virtual machine instead, takes most hard problems from game programmers to the coders of the VM. And if you simplify the interface, get closer to the (virtual) hardware, and offer a simple, integrated IDE you have a good chance of solving some of the problems.

But enough for now...
I believe I have already used way too much time posting on these issues!
Time to do some real work ;)
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1609
Location: Your consciousness.
PostPosted: Tue Feb 09, 2016 6:12 am    Post subject: Reply with quote

carra wrote:
0xDB wrote:
I second the notion that making stuff because of wanting to make it is just fine, no need to get all overly defensive and upset about it.

I'm now puzzled! What made you think I was upset with any of you? O_o. If anything, maybe just disappointed with the current general state of 2D game programming and deployment.

Must have been the use of exclamation marks and uppercase YELLING to stress words.


carra wrote:
0xDB wrote:
there ARE feasible alternatives to going down the full NIH ("not invented here") route and making classic looking games is much much easier on modern hardware and using modern environments like Godot, Unity, Construct2, SuperPowers(HTML5/JS) than learning a new virtual machine (which your thing is just going to be, another virtual machine, a new dependency to run things on).

Which alternative there is? Invoking NIH syndrome is fine when there are, in fact, alternatives, but how do the ones you listed solve what I wrote above?

They solve it by being exactly like this:
"A virtual machine instead, takes most hard problems from game programmers to the coders of the VM. And if you simplify the interface, get closer to the (virtual) hardware, and offer a simple, integrated IDE you have a good chance of solving some of the problems."

They all come with their IDE, are super easy to program/develop for (even for non-programmers), and deployment is exporting the VM for the target platform along with the game data. Zero screwing around with compilers and platform specific libraries required.

The impression is that the motivation, your reasoning behind your thing, is seeing it to fill a hole, which has already been filled, multiple times. Each system has it's own problems and quirks. So will yours. Development is always messy to some degree. Inventing another VM or standard or whatever can not solve that "issue" you want to see where there is no such issue. We already have convenience for consumers and developers in plenty of systems.

But again, create what you want to create. You don't need a sound reason to create.
_________________
0xDB
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Tue Feb 09, 2016 11:30 pm    Post subject: Reply with quote

0xDB wrote:
carra wrote:
0xDB wrote:
I second the notion that making stuff because of wanting to make it is just fine, no need to get all overly defensive and upset about it.

I'm now puzzled! What made you think I was upset with any of you? O_o. If anything, maybe just disappointed with the current general state of 2D game programming and deployment.

Must have been the use of exclamation marks and uppercase YELLING to stress words.

Oops, my bad then. Written text lacks the correct expressiveness, so I was trying to put emphasis where needed.
View user's profile Send private message Visit poster's website
Ren
Contributor

Joined: 31 Aug 2005
Posts: 271
Location: London, England
PostPosted: Tue Feb 16, 2016 8:13 am    Post subject: Reply with quote

Broadly speaking, I think this is a good idea. The idea of having a virtual compile target has been around since forever, and mainstream since the JVM. The core idea is good, but unfortunately every one so far has been a pain in the ass for one reason or another. Usually there is some stupid ideological problem where some arbitrary coding standard is enforced, or the project isn't open source, or just lack of adoption.

This comic comes to mind: https://xkcd.com/927/

I think if someone at bell labs or something had come up with a useful convention for vm's early on we'd probably all be compiling to it nowadays. That would be cool.

Anyway, assuming this project is just for personal exploration right now, I'd like to see if you can come up with any good ideas!

Random aside: I wanted to do something like this once. I found writing an emulator really tough to get my head around though. There was a lot of stuff that I realised I didn't know about computer architecture. I decided the implement the simplest thing I could get my hands on: the chip8. I was not really prepared for how tough this was! Here is my third attempt, which works for exactly one program:

https://github.com/douglett/chip8emu

Fun times. I had plans to do a dcpu-16 emulator next, but I got on to other things somehow.
_________________
Avatar: Yu Suzuki (Virtual Fighter, Shenmue)
View user's profile Send private message Send e-mail Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Fri Feb 19, 2016 12:41 am    Post subject: Reply with quote

Haha, that comic was so true. Good one. As with many projects, where this one ends will depend way more on execution than the idea itself. That's why I want to give importance to subjects like documentation and tools, usually seen as accessory or done as an afterthought.

I tried to compile your emulator (shouldn't be hard). Shamely, I'm too lazy to set back up SDL1 libraries after I already changed my configs to SDL2. Still I looked at your code, that chip is really easy! (only 16 opcodes?). Kudos for getting it working, even if it only runs 1 rom ;)
View user's profile Send private message Visit poster's website
tcaudilllg
Newbie

Joined: 17 May 2013
Posts: 7

PostPosted: Fri Feb 19, 2016 5:02 am    Post subject: Reply with quote

I think most people here have the common experience of having tried to roll their own game maker (I know everyone but the career artists have made their own game engines). There were lots of such efforts in the early 2ks... none of them succeeded except for the titular titled "Game Maker" (which I think was a holdover from the Amiga days), and RPG Maker, which itself owes its acceptance and advent (in the west) to what most of us see as quite ungrateful hypocrites. To be sure, most of the game makers had the common shortcoming of being difficult to use and very buggy on account of Linux support (a goal neither Game Maker or RPG Maker ever strived for), so it's understandable why they failed. RPG Maker also offered royalty free graphics, and had the benefit of having been advertised in game magazines, so there was an esteem factor which smaller, poorly advertised efforts like ours couldn't really match. It didn't help this community could hardly manage to create a common stock art pool until after RPG Maker had taken over. People kept expecting that some day, their worth would be recognized and someone -anyone- would come forward to complete the puzzle. But the hostility and competitiveness of the community prevented this from ever happening, and so only the (rarely) polished products tended to be one-man shows. With the demise of RPGDX, most of these older makers fade from memory. To this day the problem remains the same: people think they are entitled to make it big and so won't give a second thought to betraying one another to climb the ladder/finish first in the race. If people begin to realize they aren't the clever idiots they make themselves out to be then maybe indie development will coalesce and the scene will prosper with newfound creativity and quality.
_________________
Try Gamestar, a game making system for Firefox
View user's profile Send private message Visit poster's website
Ren
Contributor

Joined: 31 Aug 2005
Posts: 271
Location: London, England
PostPosted: Fri Feb 19, 2016 6:30 am    Post subject: Reply with quote

@carra actually there are many missing opcodes - the problem I had was that when reading the chip8 documentation, sometimes I would misunderstand it and the operation would do something slightly wrong. Usually this would be reading the wrong number of bytes, or reading a jump address from the wrong place. So, I had to get a super simple program, and just implement each opcode one at a time while trying to test that it was giving the right output. Thats why it only runs one program! Badly! I think reading tech documentation is a skill in itself, haha.

Heres the document I was trying to follow: http://devernay.free.fr/hacks/chip8/C8TECH10.HTM . Apparently there are supposed to be 36 instructions. Shows my average attention span, lol.

Anyway, the point of mentioning this is that CHIP-8 is a good starting point for understanding emulation, if you find such things useful for your project, or if anyone reading ever decides they want to give emulation a go. There are many good teaching resources online for this type of stuff, it's classic computer science :)
_________________
Avatar: Yu Suzuki (Virtual Fighter, Shenmue)
View user's profile Send private message Send e-mail Visit poster's website
tcaudilllg
Newbie

Joined: 17 May 2013
Posts: 7

PostPosted: Sat Feb 20, 2016 1:31 pm    Post subject: Reply with quote

In essence, the "universal platform" you're talking about already exists. There are like, 4 in fact: Java, Javascript/HTML5, Flash, and Unity. All of these technologies share issues that have nothing actually in relation to the technologies themselves, but are a direct consequence of their development models. Commercial development is by its nature insecure, because it is invariably beholden to competing priorities and interests. Deadlines must be met and deadlines mean things must go un-analyzed and unfixed. But aside from the insecurity, none of these technologies really has any advantages over any of the others, aside from the fact that 3 of them are proprietary. That's reason enough, though, for them to be abandoned in the eyes of decision makers. That last term -- "decision maker" -- is the real fly in your ointment. How could you obtain the backing required to keep up with requirements without money? Venture capital? You need connections for that... Kickstarter isn't enough. Nobody succeeds by their own balls anymore... behind every successful initiative is some kind of big money backer, even if their involvement is made secret. How do you make connections with big money? You have to go to a school, a -prestigious- school. So many authors out there who do manage to make a living selling niche product, but they never make it really big... why is that? Because the doors are closed to people who have public university degrees, no matter how talented they actually are. That's the reality in today's economy.
_________________
Try Gamestar, a game making system for Firefox
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Sun Feb 21, 2016 3:54 am    Post subject: Reply with quote

Tcaudilllg, you make some interesting and sound points. Indeed, Java and Flash are popular virtual machines (even if their implementations are big security holes and need updating every other day, but I digress). However there are other issues you mention that don't seem to point in the same direction I am aiming for this project.

First things first: as 0xDB said, I am set on doing this mainly because I find it fun. And I will still try to complete it even if halfway there it is clear that no one else cares about this system. The thing is just that, once I have decided to commit a lot of my time to doing this, I might as well try to make it attractive and accessible to any other person who might be interested in the idea.

With that said, let me now make some general comments on what you wrote:

- You mention raising capital, business connections and the like. Why should any of this be needed? I am not aiming for any commercial benefit, nor seeking the adoption of any game studios. In fact the idea is that the project will be fully open source, and any roms you download for this console are very likely to be free too (how would you charge money or prevent piracy in such a system?). It is directed towards hobby programmers or free indie projects, no money or company structures involved anywhere.

- The platforms you mention (Java, Flash, HTML5, Unity) are quite different from what I intend here, mainly in that they are much more general purpose. The system I am developing has a very specific purpose: easy development and playing of retro style 2D games. And because of this limitation, it will also be quite more simplified and tweaked to this end than any of the previous. Yes, you can do 2D games with Java, but you have to choose from a plethora of graphics and sound libraries, you must write code to handle your window losing/gaining focus, find out how to read joysticks, detect each machine capabilities, implement some kind of timing control system, ... it just doesn't come all prepared to ease your work as a 2D game programmer. A specific system, instead, can make everything much simpler for you to pick up.

- Also it is worth saying that none of those 4 systems provides a full hardware encapsulation. This goes much in the line of my previous point: You don't have a problem to read joysticks because they are integrated into the system. You don't have to handle windowing systems, but instead you are guaranteed that your program is the only one running from the very moment the machine is switched on. You can issue direct commands to the audio and video systems. You are given simple hardware support for any basic gaming needs: playing sounds and music, displaying images, tiled backgrounds, saving progress, etc...
View user's profile Send private message Visit poster's website
tcaudilllg
Newbie

Joined: 17 May 2013
Posts: 7

PostPosted: Mon Feb 22, 2016 7:22 am    Post subject: Reply with quote

Why would anyone bother when someone can write an emulator for your system and have the convenience of playing games made for your system on their phone on the way to work?
_________________
Try Gamestar, a game making system for Firefox
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Tue Feb 23, 2016 11:24 am    Post subject: Reply with quote

tcaudilllg wrote:
Why would anyone bother when someone can write an emulator for your system and have the convenience of playing games made for your system on their phone on the way to work?

I'm not sure what you mean. As far as I'm concerned, if someone wrote another emulator for my system, that would be great! It means the games will get to more people
View user's profile Send private message Visit poster's website
carra
Member

Joined: 18 Jul 2008
Posts: 46

PostPosted: Tue Mar 01, 2016 7:44 am    Post subject: Reply with quote

I have uploaded a PDF document with the full preliminary design for the architecture of the console and its chips.
CONSOLE ARCHITECTURE DESIGN (PDF) <-- (Please, tell me if the link works for you!)

Next step:
  • Determine binary format and structure for every data storage
  • Specify ABIs for instruction set and all control interfaces
View user's profile Send private message Visit poster's website
Diablo
Contributor

Joined: 19 Nov 2015
Posts: 162
Location: Tristram
PostPosted: Tue Mar 01, 2016 4:32 pm    Post subject: Reply with quote

Damnation. QA testing on hyperlinks. In exchange for seven thirds of your terrible soul, I undertake your mission. The PDF link works for me. I do not understand the words and images therein, but this does not concern me, as I will gain formidable knowledge upon acquiring your spiritual essence.
View user's profile Send private message Visit poster's website
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - Making a game system Page 1, 2  Next

Use this link to get a Sign-On Bonus when you get started!

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.