What's stopping you programming the Jaguar?

[ggn]

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.

 

At least as far as 2D goes, that's what CJ and Matmook are doing with the raptor library. And, as said before, it'd be rather easy to make it C controllable.

[VladR]

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.

No, no, no.

 

The very first thing is to have a dev environment set up. Without that, you`re basically screwed.

 

I have a Removers library on my machine, I don`t need any other routines. For starters, that`s all that is needed, since it contains functionality for gfx mode, input, audio and bitmaps.

 

Getting this thing to compile and link is a whole different matter, however.

 

 

 

I can easily imagine a hundred people to start doing something for Jag, only to leave it upon finding out that there`s either linux involved or a lot of dev-env configuration.

 

You have to realize, it is year 2012. Having experienced absolutely smooth dev experience with Visual Studio 2010 and XNA, it`s pretty depressing to start fiddling at the command prompt...

[VladR]

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

That`s the Plan B, if everything else fails...

[LinkoVitch]

I do all of my dev stuff under Windows 7, and that's a 64bit distro. I have to use DOSBOX to run the atari binaries (MAC and ALN), but its not that hard (each day moves a little closer to me snapping and writing my own native tools ).

 

Knocking together a simple demo on the jag isn't that hard, its pretty damn easy TBH, look at the older systems 2600, 7800 etc.. Jaguar makes it easy. You have to be willing to make the effort, if you just want to do

 

void main(int argc, char *argv)

{

gamegonow(lolz);

return 0;

}

 

You are missing the point of coding for a retro system I think. If your primary aim is pure and simple game and you have no interest in the challenge added by an older system, or a love for an older system, then you probably shouldn't be writing a game on an older system.

 

If you want to learn a load about how computers actually work, want some challenge, want to spend a few hours trying to shave a few ms off a loop etc, then stuff like the Jag is great fun. It's certainly different to modern programming systems, it's not gentle, its not forgiving, there is no IntelliSense automagics, just you and the assembler taking on the evil forces of the Jaguar silicon...

 

Don't try to push the system from day one, learn it 1st! The 1st thing I did was to get an object on the screen, then rudimentary parallax scrolling and a bit of an unlimited bobs screen with some blitter action.. each bit added a stage at a time, each bit learning a new aspect. I didn't touch RISC stuff for quite a while.. that 1st simple demo I wrote.. I think it took me a few nights of hacking away for a couple of hours before bed.. GREAT fun.

 

Since then I have just applied the same logic, break up the task into manageable chunks, work on a bit at a time. Don't overwhelm yourself with trying to write the whole thing from scratch in one go especially for a system you are not familiar with. I don't think C is the answer for the jag, to get at any of the real power I imagine you are going to have to get up-close and personal with the hardware, write your own libraries, build up your tools, make friends and have some laughs.

[+Gemintronic]

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

That`s the Plan B, if everything else fails...

 

No dice on Portable Ubuntu? It would make it look like a native application..

[LinkoVitch]

 

I can easily imagine a hundred people to start doing something for Jag, only to leave it upon finding out that there`s either linux involved or a lot of dev-env configuration.

 

You have to realize, it is year 2012. Having experienced absolutely smooth dev experience with Visual Studio 2010 and XNA, it`s pretty depressing to start fiddling at the command prompt...

 

Not much need for config, should take a small amount of time, you just need the tools in your path, and you are pretty much set.

 

Assembler, Linker and make will .. ahem make your life simple.. it's all I use

 

ALN, MAC and MAKE.. they are just in my path... I write code, type Make and bish bash bosh.. executable

[GroovyBee]

You have to realize, it is year 2012. Having experienced absolutely smooth dev experience with Visual Studio 2010 and XNA, it`s pretty depressing to start fiddling at the command prompt...

 

If you think that is depressing then debugging anything on real hardware will drive you nuts when all you've you can do is say "Got here!" by changing the screen colour or sending text over from your Skunkboard in JCP console mode.

[VladR]

I do all of my dev stuff under Windows 7, and that's a 64bit distro. I have to use DOSBOX to run the atari binaries (MAC and ALN), but its not that hard (each day moves a little closer to me snapping and writing my own native tools ).

 

Knocking together a simple demo on the jag isn't that hard, its pretty damn easy TBH, look at the older systems 2600, 7800 etc.. Jaguar makes it easy. You have to be willing to make the effort, if you just want to do

 

void main(int argc, char *argv)

{

gamegonow(lolz);

return 0;

}

 

You are missing the point of coding for a retro system I think. If your primary aim is pure and simple game and you have no interest in the challenge added by an older system, or a love for an older system, then you probably shouldn't be writing a game on an older system.

 

If you want to learn a load about how computers actually work, want some challenge, want to spend a few hours trying to shave a few ms off a loop etc, then stuff like the Jag is great fun. It's certainly different to modern programming systems, it's not gentle, its not forgiving, there is no IntelliSense automagics, just you and the assembler taking on the evil forces of the Jaguar silicon...

 

Don't try to push the system from day one, learn it 1st! The 1st thing I did was to get an object on the screen, then rudimentary parallax scrolling and a bit of an unlimited bobs screen with some blitter action.. each bit added a stage at a time, each bit learning a new aspect. I didn't touch RISC stuff for quite a while.. that 1st simple demo I wrote.. I think it took me a few nights of hacking away for a couple of hours before bed.. GREAT fun.

 

Since then I have just applied the same logic, break up the task into manageable chunks, work on a bit at a time. Don't overwhelm yourself with trying to write the whole thing from scratch in one go especially for a system you are not familiar with. I don't think C is the answer for the jag, to get at any of the real power I imagine you are going to have to get up-close and personal with the hardware, write your own libraries, build up your tools, make friends and have some laughs.

I think, I`ve had my fair share of shaving off couple miliseconds here and there, about 25 yrs ago on both PC and Atari 800 (where I used to code in pure hexa, since there was not enough memory for the morbidly long assembly instructions).

 

You are however wrong, if you think that the only way forward is to use assembly language. The end results is all that matters. The gamer doesn`t give a damn if the game was written in pure assembly, C, Basic or Logo.

 

You can get a pretty nice end result even with a very basic 3D scene. There`s quite a lot of different 3d setups that haven`t been explored on Jag, yet it is more than obvious that Jag has enough power for that.

 

And more than a couple of 3D-in-2D set-ups that also haven`t been explored and used.

 

So, what if someone, instead of trying to run some renderer 7.3126679% faster, just used a common sense and created great-looking games ?

 

 

 

Free time is a very precious commodity. What is the point (other than someone considers that to be actual fun) to be an order-of-magnitude less productive ? Does the player benefit from the fact that the game takes 10 times longer to produce ?

 

 

There are Eclipse dev ASM set-ups for Atari 800 these days ! You can see hundreds of lines of code at the same time.

 

I can very clearly remember the pain of juggling tens of A4 sheets (full of ASM) on the bed, trying to find "that" piece of routine. Was it fun ? When I was 13, yes. There was no other way at that time.

 

But in 2012 ?

[+CyranoJ]

You are however wrong, if you think that the only way forward is to use assembly language. The end results is all that matters. The gamer doesn`t give a damn if the game was written in pure assembly, C, Basic or Logo.

 

Lot's of so-called Jaguar 'fans' will shun anything that's written in pure assembler on the 68000. God forbid someone uses a compiler! Oh the horror!

[GroovyBee]

... pure assembler ...

 

Nah! I much prefer my assembler to be down right dirty.

[LinkoVitch]

I think, I`ve had my fair share of shaving off couple miliseconds here and there, about 25 yrs ago on both PC and Atari 800 (where I used to code in pure hexa, since there was not enough memory for the morbidly long assembly instructions).

 

Morbidly long assembly instructions!!! but you want to write in C, but would prefer .NET!? What assembly language was this? I have always found ASM rather terse in terms of instruction length, especially stuff like 6502

 

You are however wrong, if you think that the only way forward is to use assembly language. The end results is all that matters. The gamer doesn`t give a damn if the game was written in pure assembly, C, Basic or Logo.

 

I agree 100% that the end result is all that matters, if it's fun and people like it, it can be written in LISP or 4GL, doesn't really matter. However, you are pretty limited with what resources and tools you have on the Jag.

 

Depending what you want you may need to write portions of your game in ASM, and some in C or some other high level language. If you are wanting to push as many polygons as you can and do texture mapping on the jag I think you are gong to not want to waste any ticks that you don't have to, it's only a 25MHz machine, with some interesting bus architecture. So you would probably be better off coding at least portions of your 3D engine in ASM to get the speed to make it fun, I may be wrong.

 

But the facts are as you have seen yourself, there is no all encompasing C compiler for the jag, so either you are going to have to write one, get someone to write one for you, or make do with what is at hand and write the code in assembly. Then you will be able to prove that C is sufficient for what you want and have fun (hopefully) writing your game/demo etc. But if those tools you think the Jag needs don't exist, the only way they are going to exist is if somoene writes them... There is nothing stopping you doing this, or at least assisting in their creation.. go for it! the more the merrier.

 

 

So, what if someone, instead of trying to run some renderer 7.3126679% faster, just used a common sense and created great-looking games ?

 

Cool, I look forward to seeing it.. of course claiming that anyone who doesn't think the same way as you has no common sense isn't exactly the best way to win friends

 

 

Free time is a very precious commodity. What is the point (other than someone considers that to be actual fun) to be an order-of-magnitude less productive ? Does the player benefit from the fact that the game takes 10 times longer to produce ?

 

I write my stuff for my own amusement, I like the challenge and the acomplishment of doing so, I have taken a great deal of pleasure seeing my code put to good use by others, and also knowing it has helped in some small way to get some more games out there on the Jag. I have enjoyed tackling problems people have found with it and enhancing it in the process.. I am not going to say I do this for the people of Jaguarland, no, I do this for me, for my kicks, I am glad they like it, makes it more fun for me

 

Howlong it takes me to reach a goal, no one is paying me for this, it's upto me. It hasn't taken me terribly long or been terribly difficult to get the SE where it is today, there has been a LOT of slacking off I doubt if I had written it in C it would have taken me any less time (and I doubt it would fit in the DSP RAM either )

 

There are Eclipse dev ASM set-ups for Atari 800 these days ! You can see hundreds of lines of code at the same time.

 

I use notepad++, it's ossum!

 

I can very clearly remember the pain of juggling tens of A4 sheets (full of ASM) on the bed, trying to find "that" piece of routine. Was it fun ? When I was 13, yes. There was no other way at that time.

 

But in 2012 ?

 

I don't print out code to debug it, I just edit it in the editor, on my PC...

 

And remember, this is a RETRO console, one of the most unloved ones (alas), so things are a little sparce, as I have said, you want shiny tools, write them or get someone to write them for you. Wishing for them doesn't get them available any sooner.

[VladR]

Morbidly long assembly instructions!!! but you want to write in C, but would prefer .NET!? What assembly language was this? I have always found ASM rather terse in terms of instruction length, especially stuff like 6502

A800 has 6502. So, the single source code line e.g. LDA $4000+1, can occupy even 10 bytes (I used ATASM). However, with hexa, it`s just a couple Bytes. I clearly remember, I had to switch to hexa, since there was not enough RAM for the actual source code.

I was writing editor&compiler of assembly language that used just tokens (instead of regular ASCII), thus it occupied only slightly more memory than the actual machine code.

Of course, there were a lot of other nice features, like instant syntax check, and so on. Compile times were practically instant. And the whole thing could easily move itself to any place of memory.

 

Depending what you want you may need to write portions of your game in ASM, and some in C or some other high level language. If you are wanting to push as many polygons as you can and do texture mapping on the jag I think you are gong to not want to waste any ticks that you don't have to, it's only a 25MHz machine, with some interesting bus architecture. So you would probably be better off coding at least portions of your 3D engine in ASM to get the speed to make it fun, I may be wrong.

Yes, small parts, like couple routines - that can be manageable.

 

My break-down, sorted by productivity gains looks like this:

1. Tools / Loading - written in .NET, zero bugs/crashes mean radically less time devoted to tools that don`t make it to final game

2. Gameplay / AI - written in C++

3. Tight rendering routines - shaders - ASM

 

Situation on Jag :

1. Tools/Loading - We obviously don`t have .NET (Mono) on 68000 (even if it would be just precompiled IL), since that`d take the precious RAM that we don`t have.

Lower performance is of no importance - does it matter much if the loading takes 10 seconds longer ? Not really. But it saves enormous amounts of time. I have experienced this first hand.

 

2. Gameplay / AI - C++ would be preferable, but PureC may have to be enough. Since in past I`ve done exactly that, I can compare the productivity easily. In PureC - lots of memory bugs, very long debugging, other issues. In C++ - practically no memory crashes, code "just works".

True, I may have been a worse coder at the beginning, but still...

 

3. Shaders - yep - we need ASM here, but it`s only for a very small part of the whole codebase. We`re probably talking about 1000 lines of code here (for non-3d stuff), so that`s manageable.

 

But the facts are as you have seen yourself, there is no all encompasing C compiler for the jag, so either you are going to have to write one, get someone to write one for you, or make do with what is at hand and write the code in assembly. Then you will be able to prove that C is sufficient for what you want and have fun (hopefully) writing your game/demo etc. But if those tools you think the Jag needs don't exist, the only way they are going to exist is if somoene writes them... There is nothing stopping you doing this, or at least assisting in their creation.. go for it! the more the merrier.

Writing tools has never been my thing. I had to write many of them, for my own 3D engine toolset on X360/PC/WP7. But it`s not something I specifically look forward to.

 

So, what if someone, instead of trying to run some renderer 7.3126679% faster, just used a common sense and created great-looking games ?

Cool, I look forward to seeing it.. of course claiming that anyone who doesn't think the same way as you has no common sense isn't exactly the best way to win friends

Ok, I`m sorry if that was harsh, but to me it definitely seems crazy if everyone says that ASM is the only way. 25 MHz is still lots of power. If Removers library uses GPU for blitting, then the 25 MHz don`t really matter, since the blits are as fast as reasonably possible.

 

I write my stuff for my own amusement, I like the challenge and the acomplishment of doing so, I have taken a great deal of pleasure seeing my code put to good use by others, and also knowing it has helped in some small way to get some more games out there on the Jag.

I have enjoyed tackling problems people have found with it and enhancing it in the process.. I am not going to say I do this for the people of Jaguarland, no, I do this for me, for my kicks, I am glad they like it, makes it more fun for me

 

Howlong it takes me to reach a goal, no one is paying me for this, it's upto me. It hasn't taken me terribly long or been terribly difficult to get the SE where it is today, there has been a LOT of slacking off I doubt if I had written it in C it would have taken me any less time (and I doubt it would fit in the DSP RAM either )

Fair enough. We all have different goals.

 

I don't print out code to debug it, I just edit it in the editor, on my PC...

I didn`t have a printer or disk tape on my A800, so I had to "print" everything by hand using ages-old pen&paper technique. Time-consuming, but that was the only way to debug it at that time.

 

And remember, this is a RETRO console, one of the most unloved ones (alas), so things are a little sparce, as I have said, you want shiny tools, write them or get someone to write them for you. Wishing for them doesn't get them available any sooner.

Well, I wouldn`t exactly call a C++ compiler for 68000 a shiny tool. I did find out recently that the risc in Jag is more exotic than chips in toasters or fridges, so it doesn`t have a gcc compiler target.

[rush6432]

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.

No, no, no.

 

The very first thing is to have a dev environment set up. Without that, you`re basically screwed.

 

I have a Removers library on my machine, I don`t need any other routines. For starters, that`s all that is needed, since it contains functionality for gfx mode, input, audio and bitmaps.

 

Getting this thing to compile and link is a whole different matter, however.

 

 

 

I can easily imagine a hundred people to start doing something for Jag, only to leave it upon finding out that there`s either linux involved or a lot of dev-env configuration.

 

You have to realize, it is year 2012. Having experienced absolutely smooth dev experience with Visual Studio 2010 and XNA, it`s pretty depressing to start fiddling at the command prompt...

 

I get tired of seeing posts like this and general statments.. Its not and never will be python/perl/php/c++/c#/.net/insert language here

 

asm/c are your only options at the moment unless you make your own solution...

 

If you cant fiddle at the comand prompt in linux/windows/osx then you shouldnt be developing on the jaguar....

C++/c# and higher level languages have you detached so much from hardware than joe blow can write anything these days.

 

Unless you write the converter for c++ on the jaguar its not going to happen. ASM is proven, it works, thats what the jag is mainly coded in. Deal with it or find your own solution around. Everyone seems to be ok with the assembler portion from what ive seen and im no guru when it comes to asm. Its pretty straight forward and easy to learn if you're willing to put in the time...

 

My entire dev environment consists of an includes folder with some routines ive written to make life easy in the programs i make (sys hardware equates, text,sound,networking,misc stuff)

 

ive got a graphics, sound and music folders as well to sort out the included binary files to the program and the main folder consists of MAC/ALN and the code to the program and in my case WDB for the alpine to load the programs...

 

I used ubuntu and built in gEdit....

 

no crazy stuff here.. all straight forward BUILT IN stuff with the OS.

 

The only command line other than a script or two ive written to compile the program and load up WDB and auto launch was to set permissions on the older programs (wdb,mac,aln) and set the ownership to root so i can effectivly run them in terminal...

 

With all the complaining ive seen you post you could have had something running on the jaguar by now had you put that energy into writing programs/libraries

Edited June 28, 2012 by rush6432

[GroovyBee]

2. Gameplay / AI - C++ would be preferable, but PureC may have to be enough. Since in past I`ve done exactly that, I can compare the productivity easily. In PureC - lots of memory bugs, very long debugging, other issues. In C++ - practically no memory crashes, code "just works".

True, I may have been a worse coder at the beginning, but still...

 

In my experience of C++ there is a single heap manager so "new" eventually calls "malloc" and "delete" eventually calls "free". To say that C++ gives you less memory crashes than "C" is just down to personal coding style and debugging ability.

 

3. Shaders - yep - we need ASM here, but it`s only for a very small part of the whole codebase. We`re probably talking about 1000 lines of code here (for non-3d stuff), so that`s manageable.

 

Might be a small part of the code base but its where most of the time will be spent.

 

Writing tools has never been my thing. I had to write many of them, for my own 3D engine toolset on X360/PC/WP7. But it`s not something I specifically look forward to.

 

Writing tools is part of the "job" when you start on retro console programming. Some are tailored to the project at hand and some will be used over many projects.

[+CyranoJ]

Oh stop it, you both know the only way you get anything written on the Jaguar is to endlessly discuss it, re-discuss it, involve people who can't code, make some coffee mugs, discuss it some more, start a competition, then cancel the whole thing after taking pre-orders

[VladR]

[+CyranoJ]

asm/c are your only options at the moment unless you make your own solution...

 

We did, it's called RMotion

[VladR]

Not much need for config, should take a small amount of time, you just need the tools in your path, and you are pretty much set.

 

Assembler, Linker and make will .. ahem make your life simple.. it's all I use

 

ALN, MAC and MAKE.. they are just in my path... I write code, type Make and bish bash bosh.. executable

Sure, if you are already developing under fully installed and configured linux distro, then it might seem so.

 

My CygWin distro didn`t even have gcc. I`ve already installed crapload of libraries, but it`s still far from a full dev env. apt-get ? Forget it...

 

It`ll take some time till I can get to smac and cross-mint installed to compile examples in Removers lib.

 

 

 

Maybe I should have been more specific, because to you guys it seems like it`s just a matter of setting PATHs.

 

 

Yeah, right - like I never set a path or anything...

[+CyranoJ]

Sure, if you are already developing under fully installed and configured linux distro, then it might seem so.

 

What are you rambling about now? I use windows 7 x64.

 

Edit in Notepad++, open a CMD window and run SMAC/SLN and 'bish bash bosh... executable in the VJ folder.'

 

If setting that up is 'too much' then you may as well give up now.

[VladR]

Sure, if you are already developing under fully installed and configured linux distro, then it might seem so.

 

What are you rambling about now? I use windows 7 x64.

 

Edit in Notepad++, open a CMD window and run SMAC/SLN and 'bish bash bosh... executable in the VJ folder.'

 

If setting that up is 'too much' then you may as well give up now.

I`ll see about that when I finish installing all dev packages into my CygWin distro (it`s 33% now, will probably take whole night).

 

It surely doesn`t sound terrible, if it`s just those 2 steps (and it works).

 

So far, I can compile a regular pureC code (I got the Hello World up&running in the emulator). As I said, I need Removers lib (which, for obvious reasons, is set up for linux) to start producing anything meaningful, since i`d rather concentrate on production of the actual games.

 

Hopefully, I`ll get to it again during upcoming weekend.

[rush6432]

I dont have any live cd or specific setting of any paths....

 

literally copied over aln/mac/wdb from linux version of atari tools to a FRESH Install of ubuntu 10.10, created a simple bash script that calls aln and mac to get the binary compiled and i run wdb to upload. other than that its as simple as making folders and organizing it all how you want. just make sure when compiling if you use the include command on specific .s files that you call to the right path they are in inside of that folder, ie root folder and you call to gfx folder for file.s do an include "gfx/file.s" all common sense there.

 

Im not sure why you are sooo opposed to Linux live cd.

 

linux honstly....much better than winbloz and most get used to it quick and find they like it better...

 

Now for C. i cant help setting that up as i personally dont use C on the jaguar. I feel more at home with asm personally..

 

Might get ahold of dr Typo. he has done a few demos in C...

Edited June 29, 2012 by rush6432

[VladR]

I`m guessing Cyrano is also talking just about compiling assembler, since that`s what he programs in. I can see how a single executable/tool might be enough to get the asm compiled.

 

Theoretically, when my cygwin distro finishes installation, and I install smac + crossmint, the Removers lib might just get compiled. Looking forward to testing that soon....

 

 

 

Guys, since you already have a full dev-env set up - just take a Removers lib and compile few examples under Windows (I know it works under linux, so it`s of no use if you do it there).

 

Could you do that ?

 

 

 

Oh, and I really don`t want to start the linux/win flamewar. Don`t get me wrong - I don`t mind getting paid for working with its various distros at work, it`s more of a "Apage Satanas"

[LinkoVitch]

I`m guessing Cyrano is also talking just about compiling assembler, since that`s what he programs in. I can see how a single executable/tool might be enough to get the asm compiled.

 

Theoretically, when my cygwin distro finishes installation, and I install smac + crossmint, the Removers lib might just get compiled. Looking forward to testing that soon....

 

I have weird OCD's... so Assembly is Assembled, high level languages are compiled... (I'm my own kind of special).

 

I write any tools I need in C or C++, I have mingw installed under windows, so if I need some C tool, I can scribble one down and just runn gcc right there from the windows cmd shell.. Anything a little bigger and I'll user make.

 

If you want an IDE to go with it, grab Codeblocks, it will install MINGW for you, if you don't like Notepad++ etc

 

Any yeah, dev under windows (and linux) is just a few path settings really.

 

Rush: you should look into using Make rather than bash scripts to assemble your stuff chief, have a google around it, handy developer tool.

[rush6432]

meh im just too lazy heh. You know us americans

 

eventually im sure ill get around to it.

[LinkoVitch]

meh im just too lazy heh. You know us americans

 

eventually im sure ill get around to it.

 

It's worth a few minutes to have a look at.. does clever things like only build assets if their source has changed etc. Not that build times are huge on a modern system, but it shaves a few seconds off. I have also had it do things like build graphics assets as the original images have changed using image converter tools etc.

 

Can have simple config for differing builds, so "make debug" could build the project slightly differently to include debugging code, vs the plain vanilla version.. If you grab my SE there is a Makefile in that that should hopefully give you an idea of syntax etc.