Gorf

IMHO, that's not a bad way to go. A while back, actually quite a while back now, I had a similar experience with OpenGL and C on SGI. Used to jam on those computers professionally and I really liked them. One day, I was reading something about OpenGL, and stumbled on a really great Oreilly demo code. It had just the basics, keyboard, mouse, and a graphics loop. I think it drew a cube, or something simple. Basically, it was turn on the lights, setup the polys, do your transforms, and such... The code filled maybe two screens. It was enough to build on, so I did. At first, I did my own shapes, then I built up an array of polygons with cool colors and had a few hundred of them spinning and moving on the screen. It took a bit to get each thing done. File I/O, graphics, etc... and ended up producing a nice little STL file viewer that was actually useful. On a modern machine, it can render maybe half a million polys no sweat, and do so at a reasonable frame rate. Viewstl is the project name, and it's still out there, if you want to see the rank amateur I am My point is that took maybe a few months to get done, and it was fun, and it was possible for somebody willing to think it through a little. I know there isn't something cool like OGL on the Jag, but maybe there could be. That spinning cube, or maybe sticking with 2D, sprites moving and bouncing maybe with the game controller might just get people cooking. The key is to take as many of the barriers away, leaving people with something they can just chip away on, getting stuff done. This was done years ago with my getting started lessons of JSII. They were available to everyone at one point. JagChris is the only one that ever bothered to use them. They were as simple and self explanitory as you could get. I even had idiots complaining about how 'pedantic' they were!!!! Imagine that!! Clearly I was'nt pedantic enough.

You are right it's not worth it...it's just plain foolish to compare this machine with any before it. It's a completely different playing field. The only thing Jag has in common with the consoles before it is they are consoles. After that it's an entirely different way of thinking due to the multiprocessor nature of the Jag. On others helping: They have! What more else do you want? What is not out there that you need to start a game? Just name one thing!!! You can't because all you need to write a game is readily availbe on this site and many other sites. TRust me, People want it handed to them....they helping hand has been give 100 fold over and over. Ther eis no more excuses and it's clear to me those that complain the loudest are the ones who bother the least. You keep complaining about this but you have yet to site one example of it.

I see you've had no answer there poobah. Not suprised ..... however..... I've blown my Jag up a million times crashing the system running code with trial and error. There is absolutely no reason why anyone else can't do that now. Especialy now that you have 100 times the info and examples I ever had when I started to code this machine > 15 years ago. It sounds like laziness and a true lack of will to me. It sounds also as if everyone wants to wait around until someone does it for them. Grab the tools and use the examples and go for it. This is the only real hope you have. Of course you can ask questions which I will always be happy to answer but I dont even see any one(besides JagCris and one or two others) actually even bothering to do that. All I see is a bunch of wannabees complaining about stuff that is not even true. Now stop being wannabees and be doers. I am, and you can to. JUST DO IT!

Not in the embedded world. If I use printf on some of the micros I've worked with there is no space in the ROM for the application . Absolutely true, but the Jag is a little higher up the food chain. I'd love a nice set of GPU OP routines. Too much reinventing of the wheel on the Jag. Abstract away some of the arcane details and people will start writing more stuff. Although some of us can write assembly code, most people today have never seen it, and would be lost without object::method(foo). If you want a wider base of programmers, you need to step back a bit from the hardware. I think there's a big space between living solely on the 68K and Gorf-level knowledge of the RISCs. Some tools and libraries to exploit that space will bring more developers. I'd have written new tools if that was my bag....that is a science in its own right. I am a logic coder mostly. I make the games think and act. I could probably do those other things but then I'd really never get anything done trying to do it all....that is why teamwork helps. I have a team...they are slow...very slow but a team none the less. If you want these things so bad...write them...we had to from scratch and reading docs. Im no mega guru here. I read, I write and I trial and error.

Who's being secretive? I think that is yours and everyone elses inagimation. Those Lessons on JSII are mine and so is the mani RAM GPU execution, so who is this being secretive? Please....do tell us what is this 'X' and who has not disclosed it? Should I just upload every piece of source code I have written or ever write? not that it would matter since no one has done one damn thing with the tons of source readily available to the masses. I call shenanigans on you and anyone else who tries/cries this nonsense! I am working on LIBS that WILL greatly benifit those who have the balls to use them...unfortunately no one wants to do any work unless you hold their hands every step of the way. The only one you have any hope for being correct on is 0. The rest is you repeating the typical sour grapes of those that feel we write code for thier pleasure. I really dont see what anyone else can expect that has not already been handed to them. There are TONS of resource for any one with a pair to get rolling on coding the JAguar. No on is going to write it for you. Now please....prove me wrong....good luck on that.

Nothing is 'stopping' me from coding the Jaguar. I however choose not to release the games I have planned without a worthy renderer. The work is still being done. In the mean time I am doing a few mini games but they too take time and I have very litle of that. Plus I am NOT depending on someone elses code to write them. I am writting my own sprite engines and AI engines and what have you engines. All of which take time which is limited.

How about one that uses the entire system and the way recommended by Atari...which BTW was to boot with the 68k then lay off it? Not that everything Atari says is gospel...after all if we listened to them on everything, I would have never bothered to try to jump around in main RAM with the GPU. No, WE are not ALL using pre-made libs. The start up code is NOT a lib. It's is a necessary part to get the system up and running and is better equated to a bios or part of an OS. It is also recommended by Atari. There is only one useful way to boot the Jag system so re-writing the start-up is re-inventing the wheel. Using 68k based libs when there is so many more efficient ways to do things on the Jag is another. Start-up code != to a lib. Which will ONLY get you a nice 'generic' set of games. Scott used Sinister...as a guide....and from it wrote our player from the ground up entirely in DSP assembler. Using a lib/source as a guide is one thing, even I agree with this. Depending on it is another and will limit you and the type of games you can come up with on the Jaguar (or any system for that matter.) Some of us are. But we are NOT relying on other peoples libraries. Plus I am not against anyone using a library if it offers a useful function. IT just seems too many people depend on them and do very little to explore a system on their own. Simple games are the best games....but why can't you go beyond the simple use of the 68k and the OPL as a simple sprite engine? Most of the free libs are based around the 68k and would be better suited toward coding a Genny or an ST. Show me a lib that makes use of the real power of the Jaguar system,then you'll impress me....yes I AM working on such a lib....when I get time it will be finished and it will offer a much better and more efficient use of the system. Show me one example. Clone or otherwise. Outside of doom which a few people have actually had use of, it aint happening. I think you mean that is how you 'learned' how BSP trees work. That is very different than just using the code and never actually learning anything about the actual functionality of a BSP system. VERY different than cloning code. Again learning something by using something else as a guide is one thing and that is how everyone learns anything. Being a copy cat is hardly impressive. For novices, I have no problem with libs. For people that have claimed they have coded for years, its almost inexcusable. Even I have used the 3D renderer supplied by Atari, but even then we greatly optimized it(and it still sucks performance wise.) This is why I am working on a ground up renderer. It is also why I have not release any of my 3D apps. I want them to be optimal and effecient to the best of the Jaguar's ability. Im in no rush to release anything if it means releasing garbage or for he sake of bragging rights or in hopes of amking others look like they are doing nothing like some around have done.

Yes. No they have not been fixed. In fact the latest bugs were reported in the latest versions. I've been telling our tool man about these bugs for a year now. Our tol man like most of us has real lofe issues to deal with so Im not blaming him, nor have I forgotten about his hard work. Most of my games are in too far deep to bother converting over to tools that are still not working enough to deal with what I am doing. I want those tools for future endevors. Like the game that was formerly Gorf 3D. If he indeed fixes those bugs and I am sure he will when he gets a chance, I will consider moving my current code to them, but since we are getting serious blow ups in some circumstances it just not worth trying to move them over to SMAC/SLN. I dont have the time...I have more than enough on my plate. Plua you are talking about doing this from scratch as these are as far as I can tell all assembly and 6502/68000 are not compatible with J-RISC instruction wise.

You did not need a Skunk board to develope. There are many cheap and simple ways. The fact is no one is writting any Jag worthy games from the ground up. They are porting rehashes of ST games, and in some cases using pre made libs. All fine and dandy but where's the beef? I too have a few simple games Im working on but Im looking to push the Jaguar once I get my renderer finished. These things take time. Anyone can write simple games. Using the Jaguar's real power in the GPU/DSP , Blitter and OPL need a lot of hard work and laborious debugging. The sources for several games were released over a year ago now and not one person even made use of those. The Jaguar is not a cakewalk to code for if you want to do something that truly takes advantage of the ability of the machine. They are being worked on by some of us but we have lives and jobs and family to deal with. They will come and you will see them, Lord willing.

By sprites you can mean one of three things. OPL objects as sprites, Blitted Sprites or straight up software sprites. I recommend using the OPL. However this is not a 'little' lesson as you do need to understand how the OPL and it's list(s) operate. I think you should start out with a software based sprite, then use the blitter to replace the software draw, then use the OPL. Regardless, you will still need to know what to do with the OPL before you can use any of these methods on the Jaguar as it is the OPL that allows you to put anything on the screen to begin with. The OPL is indeed the backbone of the Jaguar's video system and you can't display anything without it...unless you want to write with really tight timing and precision directly to the line buffers...but you still need to set up the OPL minutely even for this. You have the 6 lessons I posted. Take a look at those as you will see how the OPL is dealing with the screen. If you want help. Let me know. I will show you how to add more objects to the list. I am working on a skeletal source for using the OPL as a sprite engine. It's got a ways to go but it uses the GPU to deal with the list where the lessons use the 68k and that setup is intended mainly for a 3D buffer and not exactly ideal for a 2D sprite based engine, although it will work for that if you want it to.

I avoid this but have tested this and it seems to be fine as long as the JR goes to a long aligned address outside the page. Since all instructions fall on some even numbered address you should not encounter any issue as long as you follow the rules. The bug is not effected because of the PC as far as I can tell. Also, according to Downix who has studied the nets, it is based on a lack of adequate power supplied to the MMU during main bus accesses. It causes a pipeline issue because outside of local the pipeline does not work correctly. This is why you need to clear the pipeline when jumping from main to local or local to main. Remember, the pipeline adheres to the 32 bit nature of the internal space of the RISC's. Outside of the RISC space its another ball game. I do not think you will encounter any issues if you just stick with the rules provided. Of course you are welcome to run your own tests to show us the error of our ways....just add any new rules you find to this thread if you do indeed find any such issues.

Probably something we need to consider in the plastics drawings. Perhaps add a millimeter or two of space to ensure these other games fit....and hopefully execute.

Time! Well... the lack of to be exact . Excuses, excuses.....( and quit stealing mine .)

Looks promising beoran. I'll have to check it out when I can find a moment. Thanks for your efforts.

I kinda agree with ZeroSquare on this one....I never had an issue with wired controllers. But GB, what's a guy gotta do to convince you to do some coding for the Jaguar?