What's stopping you programming the Jaguar?

[Atari_Owl]

Fair enough

[+Stephen Moss]

The more I tried to find a genre that appealed to me that hadn't already been covered by previous Jaguar developers, the more discouraged I got. Sprite-scaling racing games (Atari Karts, Super Burnout), fighting games (Fight For Life, Ultra Vortek), shoot-'em-ups (Raiden, Zero5), FPSs (AvP, DOOM, Wolfenstein), etc...

It would be almost impossible to find a genre on any system that was not covered during its liftime so if that is your criteria for producing something you will never produce anything unless you create a new genre and even then it will probably be a derivitive of and existing genre.

Even professional developers have that problem as shown above by your multiple examples of games in the the same genre, it could be argued that at thier core all games in a specific genre are the same game, however there are enough difference between them in terms of graphics, bonuses, control, storyline and probably even framerate to make people want to play more than one of that genre or to prefere one over another.

What you have to do is find a genre you like and try and make something like that but with your own twist. For example lets say you are a big fan of a certain game but you think that it would be better with X move, Y weapon or played with a Rotarty controller then why not start by making a similar game with your improvments and see if it really is better.

 

The Jag dosn't have a single scrolling Beat 'em up either

I assume you mean something like Streetfighter in which case don't Kasumi Ninja and Dragon - Bruce Lee Story fall into that catagory? I can't remember Kasumi Ninja but IIRC the playfield on Dragon is more than a screen wide.

[Atari_Owl]

Hi Stephen

 

I think he means something more like Streets of Rage or Double Dragon (The REAL Double Dragon not that DDV nonsense) where they sort of continuously scroll?

Edited July 7, 2010 by Atari_Owl

[Mord]

For me a lot of it has to do with time and the lack thereof. But part of the reason for the lack of time is because I get distracted awfully easily so perhaps the thing that would benefit my own jaguar programming (Assuming I could focus long enough to start something) would be a small group working on the same project. There are times when that actually helps kick gears into place.

 

Oh then there's the heat.

 

Summer is always a write off these last few years. High Heat = Low Productivity. Next year I'm going to see about getting an air conditioner or something.

[minuS]

It would be almost impossible to find a genre on any system that was not covered during its liftime so if that is your criteria for producing something you will never produce anything unless you create a new genre and even then it will probably be a derivitive of and existing genre.

Luckily, that isn't my criteria I agree with your entire post, but my point was that the genres I like aren't merely present on the Jaguar, but actually well represented. What I realised as I developed my ideas was that I was constantly moving closer to existing ideas. The_Laird's suggestion of a 2D beat-'em-up, however, has genuinely intrigued me...

[JagChris]

 

C is...

_Hello(void)

{

fprint("Hello"); */Print Hello /*

}

 

or something close to that.

 

 

lol still not quite that easy on the Jag.

 

 

I started back in 97-98 learning assembly for the jaguar and tore apart examples and modified code and played with it and tried to combine examples and such and learned it by trial and error. it took quite a while but over the course of a year or two tinkering and writing simple programs and slowly advancing i ended up learning quite a bit about the machine and how to control various parts of it.

 

i use a litle bit of all the processors and ive come up with simple 2d games that can have some pretty decent effects. However like gorf said, there are plenty of exmaples out there. you just have to be willing to dig through code in the downloads section of JS2 and a few other places and try it all out for yourself and see if you can learn from it. Personally there is no better way to learn than to get a basic program like the atari bpeg example and play around with it and make changes and clean the code up and customize it and improve on it. Hands on gets you pretty far. start with simple things and move on..

 

I suggest looking at maybe native source code, slam racer, some of starcat's original simplified JDC object list examples, atari bpeg/jagpeg examples, and possibly some of the 3d atari engine stuff. sure some of it is not ideal but.... nothing really is. like i said this is just a starting point to get familiar with how things work and you can definatly see similarities between the examples/programs.

 

There is no easy starting point, you really just have to jump in and learn and absorb as much as possible and decypher it. Like gorf said, you'll compile and load code only to have it crash a million times even though you think what you coded perfectly error free (no joke) its dificult to program for. no one said it was easy.

 

Reverse engineering existing code, even C code is not ideal. Yes it can be done. And if you have a 150+ IQ like Gorf your all set. If you're me, its nowhere near optimal.

 

Lets say you know assembly on the 68k. Plenty of tutorials to teach you that. And you can make a typical 68k system print a graphic. How do you coordinate with the Jags graphics system? Well you can look through existing code and figure it out. Which may or may not take some time.

 

Or someone can be magnanimous and post a 68k-Jag introduction. How to get the gfx system working on the Jag etc.

 

My point is reverse engineering is not optimal way to go about things for everyone. Gorf posted lessons that I used to learn quite a bit.

 

I was trying to convert his makefile to work with Boz's XP setup. I have had to abandone that because the makefile for the playground lessons has far too much going on. I understand now a fair bit about makefiles and their variables but Gorfs makefile is overwhelming. I have had to abandone it. It is quicker for me to build on the hello world exercise boz has included in his setup which i'm in the process of doing.

 

This is the problem with the average user trying to 'reverse engineer' things.

 

Probably a more ideal way for people learning is to build on Boz's hello world exercise and begin adding stuff as needed to the makefile instead of having it all avalanched on us all at once.

 

Yes we can jump in and decypher a lot in time but it would really really expediate things to have help. Its not ideal to reverse engineer tons of others code right off the bat just to get up and running on the Jag. Thats just ridiculous. I look at the Doom source and I can understand a bit of it but there is no way in any reasonable amount of time I could take that and do anything with it.

 

We need to have Jag specific lessons, not on coding, there are tons of tutorials out there on that but on how to specifically code on the Jaguar.

 

Suggested lesson ideas. How to Printf ("Hello World"); on the Jag( which is covered in the Playground lessons.)

 

How to make a simple hello world 68k asm work on the Jag. Then convert that program to the GPU. These are the things needed. Jag specific stuff. To help those without monster IQ's who are learning to program, not to teach them how to program in general, but HOW TO on the Jaguar.

 

Even for accomplished coders who come into the scene, why make the scene so unfriendly that they got to wade through a bunch of ancient source code right off the bat and try to make sense of it just to get up to speed? Thats about as unfriendly to developers as Atari was back in the day.

[matmook]

 

C is...

_Hello(void)

{

fprint("Hello"); */Print Hello /*

}

 

or something close to that.

 

 

lol still not quite that easy on the Jag.

 

 

I started back in 97-98 learning assembly for the jaguar and tore apart examples and modified code and played with it and tried to combine examples and such and learned it by trial and error. it took quite a while but over the course of a year or two tinkering and writing simple programs and slowly advancing i ended up learning quite a bit about the machine and how to control various parts of it.

 

i use a litle bit of all the processors and ive come up with simple 2d games that can have some pretty decent effects. However like gorf said, there are plenty of exmaples out there. you just have to be willing to dig through code in the downloads section of JS2 and a few other places and try it all out for yourself and see if you can learn from it. Personally there is no better way to learn than to get a basic program like the atari bpeg example and play around with it and make changes and clean the code up and customize it and improve on it. Hands on gets you pretty far. start with simple things and move on..

 

I suggest looking at maybe native source code, slam racer, some of starcat's original simplified JDC object list examples, atari bpeg/jagpeg examples, and possibly some of the 3d atari engine stuff. sure some of it is not ideal but.... nothing really is. like i said this is just a starting point to get familiar with how things work and you can definatly see similarities between the examples/programs.

 

There is no easy starting point, you really just have to jump in and learn and absorb as much as possible and decypher it. Like gorf said, you'll compile and load code only to have it crash a million times even though you think what you coded perfectly error free (no joke) its dificult to program for. no one said it was easy.

 

Reverse engineering existing code, even C code is not ideal. Yes it can be done. And if you have a 150+ IQ like Gorf your all set. If you're me, its nowhere near optimal.

 

Lets say you know assembly on the 68k. Plenty of tutorials to teach you that. And you can make a typical 68k system print a graphic. How do you coordinate with the Jags graphics system? Well you can look through existing code and figure it out. Which may or may not take some time.

 

Or someone can be magnanimous and post a 68k-Jag introduction. How to get the gfx system working on the Jag etc.

 

My point is reverse engineering is not optimal way to go about things for everyone. Gorf posted lessons that I used to learn quite a bit.

 

I was trying to convert his makefile to work with Boz's XP setup. I have had to abandone that because the makefile for the playground lessons has far too much going on. I understand now a fair bit about makefiles and their variables but Gorfs makefile is overwhelming. I have had to abandone it. It is quicker for me to build on the hello world exercise boz has included in his setup which i'm in the process of doing.

 

This is the problem with the average user trying to 'reverse engineer' things.

 

Probably a more ideal way for people learning is to build on Boz's hello world exercise and begin adding stuff as needed to the makefile instead of having it all avalanched on us all at once.

 

Yes we can jump in and decypher a lot in time but it would really really expediate things to have help. Its not ideal to reverse engineer tons of others code right off the bat just to get up and running on the Jag. Thats just ridiculous. I look at the Doom source and I can understand a bit of it but there is no way in any reasonable amount of time I could take that and do anything with it.

 

We need to have Jag specific lessons, not on coding, there are tons of tutorials out there on that but on how to specifically code on the Jaguar.

 

Suggested lesson ideas. How to Printf ("Hello World"); on the Jag( which is covered in the Playground lessons.)

 

How to make a simple hello world 68k asm work on the Jag. Then convert that program to the GPU. These are the things needed. Jag specific stuff. To help those without monster IQ's who are learning to program, not to teach them how to program in general, but HOW TO on the Jaguar.

 

Even for accomplished coders who come into the scene, why make the scene so unfriendly that they got to wade through a bunch of ancient source code right off the bat and try to make sense of it just to get up to speed? Thats about as unfriendly to developers as Atari was back in the day.

 

You can have a look at Do The Same's source code (http://dothesame.jagware.org) if you want.

there is a lot a function and a simple makefile in it (building a jag binary is just 2 lines of code).

 

Perhaps it could help

[JagChris]

You can have a look at Do The Same's source code (http://dothesame.jagware.org) if you want.

there is a lot a function and a simple makefile in it (building a jag binary is just 2 lines of code).

 

Perhaps it could help

 

Thank you Matmook. Every bit of simplified source code helps.

[belboz]

Oh and just to clarify one thing. The old dev tools work under Vista and Windows 7. But only on 32bit versions of Windows. 64bit versions will toss up an error.

 

If your using a 64bit Vista or 7 setup, use the new tools.

[JagChris]

Barrier to entry is brutal on these things. Either people find something worth it, or not, and that's just how it is. If that barrier is high enough, there is always something else to do that gets one having fun and all that other stuff that comes with banging around on old hardware.

 

This is exactly right. Barrier to entry is everything. Absolutely. Just learning C is hard enough. Now I have to learn assembly as well.

 

We have got to do everything we can to reduce the barrier to entry in the Jag dev scene. Lot has been accomplished but more can be done.

 

Tom says he's experienced in Assembly. We need lessons that will convert x86 and/or 68k asm to the Jags GPU.

Edited July 10, 2010 by JagChris

[danny_galaga]

I picked 'something else' in both cases. Tyrant is right, not knowing how to code etc shouldn't be a barrier. For me it's about not having anything new to contribute. I'm happier with the hardware side of things, making mods (",)

[Karyyk]

A lack of time and patience really. Probably not going to get any better with a baby on the way either, heh.

[+Gemintronic]

I enjoy both BASIC and console development. Not only because higher level languages allow you to focus on game logic instead of language constraints, but, I just love BASIC. C usually has that "do it yourself" feel. Meaning, half the stuff you need is usually separate and god only knows how to create a make file. Not having a development environment ready to go puts a big hurdle in front of new developers. BASIC is a gateway drug to bigger and more complicated things.

 

Even flash carts are rare or made in small runs for the Jag. I always want at least one physical cart for each of my games. I don't want to pay flash cart prices for a one off. I certainly don't want to sacrifice my flash cart itself for that one off.

 

This is not an informed opinion. Just my reasons I currently don't make Jaguar games. This thread is so old I figured by now the Jag scene is different. Are things different now?

Edited June 28, 2012 by theloon

[GroovyBee]

I enjoy both BASIC and console development. Not only because higher level languages allow you to focus on game logic instead of language constraints, but, I just love BASIC. C usually has that "do it yourself" feel. Meaning, half the stuff you need is usually separate and god only knows how to create a make file. Not having a development environment ready to go puts a big hurdle in front of new developers. BASIC is a gateway drug to bigger and more complicated things.

 

The need to use BASIC on any console is totally reliant on other people doing the work for you because its not a common language for embedded style development. If you take up "C" programming then once you've got the machine set up to the point where you can call the "main" [1] function in your code you are pretty much good to go. Usually there will be some example assembly language code in your compiler package that you can adapt. Not directed at any console in particular the bare minimum would be: put ROM access time to something sensible (normally the CPU boots in dog slow mode), configure and enable RAM/DRAM, initialise the system stack(s), configure any clocks required, zero the BSS section, copy the DATA section from ROM to RAM, install interrupt handlers, change processor modes (if applicable), enable interrupts and then hand control over to the "main" [1] function.

 

Once in the "main" [1] function you get to use all the high level stuff. With Reboot's RAPTOR engine on the horizon it'll be much easier to get games going on the jag in assembler. I have promised to do the "C" API for the RAPTOR engine which will also ease jag development entry a bit more.

 

[1] Arrrghhhh! talking about main in the context of "C" is not the same as main in RAM in the context of the jag.

[wozencl]

Things have definitely moved on since it was posted but the number of developers remains low. There are a lot of barriers to making games in general some of which are made even harder to get over with the Jaguar.

 

It takes a lot of time, effort and patience to produce even a small demo. We have libraries to use and the new engines from Linkovitch and Reboot but they still require programming knowldege to implement. Even then you still need an idea for a game and assets with which to build it (art, sfx etc.)... Collobrative work is best way to go for newbies but these very people are the ones who are likely to quickly lose heart or get bored and quit. Heck who wants to write a hundred lines of code to see some text move around the screen?

 

We do have some teams and individuals who consistently push out content for us to enjoy but I doubt there'll ever be a massive influx of devs to this scene. It's laborious, difficult to learn for most and can be entirely thankless.

 

There's also the fact you could knock up a game in Java or using XNA in a tenth of the time and with a lot less stress. Until we have a BASIC-like language for the Jag we're pretty much dependent on Reboot, Atari Owl (apologies if I've missed anyone out) and the like to produce games for the community.

[+Gemintronic]

Yeah, I expect ALOT of work goes into a BASIC compiler. Parsing and compiling are pretty advanced subjects. It also requires a bit more altruism than most asm or C programmers can afford. This is a hobby.

 

I was hoping there was a standard C compiler, IDE and library by now. I suggested a Linux Live CD with dev tools pre-installed many moons back. It really isn't hard with Salix Linux or Puppy Linux.

Edited June 28, 2012 by theloon

[GroovyBee]

Yeah, I expect ALOT of work goes into a BASIC compiler. Parsing and compiling are pretty advanced subjects. It also requires a bit more altruism than most asm or C programmers can afford. This is a hobby.

 

There are BASIC to "C" converters so your development will end up as BASIC to "C" to ASM so its not going to win any prizes for speed or elegance but at least you'll get something going.

 

I was hoping there was a standard C compiler, IDE and library by now. I suggested a Linux Live CD with dev tools pre-installed many moons back. It really isn't hard with Salix Linux or Puppy Linux.

 

Have a look at :-

http://www.atariage.com/forums/topic/193090-removers-library-version-131/

http://www.hillsoftware.com/my-atari-projects/

[VladR]

Right now, the only roadblock I have is that I have just found out that the Removers lib is usable under linux.

 

I`m on WinXP and don`t really fancy the option of using Linux as my primary dev environment, since that will make things an additional order of magnitude slower (on top of the productivity loss due to downgrading to PureC from .NET).

 

If there`s no other way, I guess I`ll just have to use linux.

 

 

If you guys have a dev set-up with Removers lib under windows, I`d love to hear your input !

[+Gemintronic]

Someone with Linux and Jaguar C development skills might:

 

1. Download Portable Ubuntu http://sourceforge.net/projects/portableubuntu/

2. Use the portable Ubuntu environment to set up their favorite compiler, library and IDE

3. Set up a torrent with their customized Portable Ubuntu ready for Jag development.

 

Now Windows users would have no excuse not to dev for the Jag. Everyone would be using the same toolset Linux or not.

[Rex Dart]

The controller has too many buttons!

 

Just kidding; it's the price & availability of development hardware.

[twoquickcapri]

The controller has too many buttons!

 

Jag controllers are for people who like to push buttons.

[ggn]

Right now, the only roadblock I have is that I have just found out that the Removers lib is usable under linux.

 

I`m on WinXP and don`t really fancy the option of using Linux as my primary dev environment, since that will make things an additional order of magnitude slower (on top of the productivity loss due to downgrading to PureC from .NET).

 

If there`s no other way, I guess I`ll just have to use linux.

 

 

If you guys have a dev set-up with Removers lib under windows, I`d love to hear your input !

 

I remember setting up the removers library under windows. I used Cygwin for that and I definitely remember getting it to work. I think I posted a few things on the Jagware forums, so it'd be best if you had a look around there.

 

In any case the removers lib should be possible to get running either under mingw or Cygwin.

[swapd0]

IMHO having a repository with simple routines/libs would help to new developers to learn how to program the jaguar and to have something to play with.

[VladR]

That`s great to hear ! I may give it a try, then. I just hate setting up the dev env. I guess I`m not a configuration management guy...

[Zerosquare]

In any case, if your PC is not too old, you can stick with Windows and run the Linux image in a virtual machine.