Symmetry of TNG

May 3, 2003

Hi!

Some words about Voxels:

It is not that easy to make fast voxels on the jaguar due to the "vertical" nature of voxels. To get something fast on the jaguar it needs to be in phrase mode, ie horisontal direction and voxels are not.

So dont expect to port AMOK straight of and get a fluid & nice game...

It needs devious thinking and hard coding!

About Amok:

..Scavenger... I wonder if that is the "good old" scavenger from the computer scene..?

Anyhow: Good luck coding!=)

May 2, 2003

I posted this in another thread but www.ravengames.co.uk are selling Jags for £19 and posting out via courier. I think they are new units.

Just remember that it is £25 in shipping if you are going to shipp outside UK... (atleast in europe, might be even more to US... (should be!))

April 29, 2003

Hi! =)

Just whanted to post a mess here to tell you that I, for one, is still interested in the answer to this thread =)

Any luck in tracking down the replye?

..And If i may say so, Im also interested in a small "howto" make that polycount number (though I think i have figured it out, partially =) ..based on the atari "things to trye" tipp in the devman

regards

/Sym

April 23, 2003

Hi!

Yes.. the basic Mandelbrot code is a "atari example" but that code is horribly slow! ...and it doesnt use the DSP either.

So to get a program worthy of running on the jaguar some minor adjustments have to be done:

Optimize the code! Not just in waitstate removal!

Use any trick in the book to get it faster (there are a few!.. a ST can do the same fractal in ~5s or so!)

& Split the work between the 2 processors so gpu&dsp are working in parallell (as they always should =)

AND!... perhapps what needs most work... if you whant it as a "generator" with arbitrary user input, an GUI..

AND... also... to make the code use higher presision.... 32bit integer has its limitations, so you cant "zoom" as deep down as you whant, before it becomes blocky. So rewrite the code to use arbitrary precision.... (and that is perhapps a bit tricky).

A nice project though =) A similar developement as on the ST would be nice to see... to realy get a feeling for the POWER of the Jaguar! =)

to bad im buzzy already with other stuff ;o)

/Sym

April 23, 2003

Hi!

Just thought to post some of my oppinions about a keyboard interface:

---It should NOT be expencive! (since it doesnt have to be). Ie no $100 price just because it is a "new feature" of the jaguar.

---Preferabely buildable by anyone with some electronik knowhow (..so i can build it myself ;o)

---..and preferabely in a "open source" kind of way. I whant to have the oportunity to choose where when and how to access the keyboard in any code i make..And not beeing limited/inhibited by someones "" to do so.. and that is important. Since without any kind of program/code, the keyboard is just a dead pice of plastic.

---When it comes to the interface, I have to say like this: Though the serial port might be more easy to adapt it to, I beleive that it should be left for use in network games...simple as that...

(though having it running on a dsp irq would be nice &effective)

---If the Enhancedport is used... which I think would be better, there might be a problem with a slow and cumbersum readprocedure. Something I would not like to have in my code... and probably the 68k has to do it..:o/

so.. in any case optimise for SPEED!

..The fastest port i know of (with ~70Kb/s) is the joypad port... as used in the BJL mod. You even have the basic "opensource" transfercodes already... just a small prcessor working as a "translator" is needed...

ahh well... just some thoughts =)

/Sym

March 8, 2003

Thanx for replyeing!

It is a bit better now =)

Just a short note:

Well i have had some ideas on hardware and thought it could be mapped to the 2Mb cart space above the usual 4Mb one... (since it is never used, blablabla) ...But if CD uses that space then that is defenitely not an option, since I agree, compatibility with CD is a MUST!

Now i dont know where to put it? ...but you say that as long as I am not in the D??xxx (dont remember right now) region but somewhere else in the 2Mb cart space, I am home free or?

What 6Mb unused dram space in the jag does for me? ..well... adds great hope for future memory enhancements for the jag =)

Delicate SMD surgery could give me a 8Mb jaguar then... that shurely gives optimism for the future..

No got 2 go

Thanx for clarifying things =)

/Sym

March 7, 2003

Hi!

Well Im sorry but im a bit confused... I did not know the cd used $dff fff space ?!

But I would realy like to get this cleared out... (everyone else understood but me, Dooh! =)

I have tried to combine the info on p9 & p96 in the devman, and now I am even more confused..

I assume the "ROMHI=1" thing is what is valid on the jag (see p.9)

then my questions is: What is between $200 000 -> 800 000 ???

And, i thought the cd-interface was at $F14 800 -> f14 fff (p.96)

So that the space you describe ($D...) was free.... what is what?

Now my mem-map lookes like this:

FFF FFF end of rom0

F14 FFF end of cd-io (p.96)

F14 800 start of cdio

E00 000 End of cart space

D?? ???

C00 000 (end of 4Mb cart space)

800 000 Start of cart space

??? ???

400 000 (...4Mb to 800 000)

??? ???

200 000 End of ordinary internal dram

000 000 start of internal dram

Now... what is the 6Mb dram space between 200 000 -> 800 000 used for?

And does the cd use $D.. or is it $F14 ?

If ??marks here are free I se endless of possibilities to add internal ram to the jag... but perhapps I just confused =) (atleast 6Mb between $200 -> $800) and then 2Mb at $c00 -> $e00) atleast! !??

I thought the 2Mb unused cartspace was free.... I would realy like to get this sorted out... if u please =)

Thanx!

March 7, 2003

Just a thought about the Polygon Engine in BS.

I remember T-bird talking about this some time ago (might be months,years,..=) and saying that even if he "clipped out" the polyengine it would be verry hard to read/understand ..for some reason (lack of commenting?

I for one would sattle for a Detailed Technical description of "How we made BS/BSG" ...TechTalk ala ST-demos-tyle kind of thing.

Like: edgebuffer in gpuram,3edge,irq based blitt stack, what dsp does what gpu does, OP, "BlitterHack" (now what is that?????),.. whatever....

..Why? ...well in order for coders to get some coding tipps and not having to 1st invent a theory just to discover it is to slow. If he aims for similar structure of things as in BS he atleast know what approximately to get out of his code...

Something to put on your Homepage, eyh T-bird?

I for one would be your 1st "subscriber" =)

Just a thought/wish/....

cheers

/Sym

February 4, 2003

hehe

Think you just received a coded transmission =)

or they didnt doo crc checks on ascii data on the cd.

Is it exactly the same ascii garbage everytime or does it change, from time to time?

February 2, 2003

Time well spent! if you ask me =)

And you are right Doom doesnt use raycasting. Raycasting is best optimized if the walls are square blocks. Doom has arbitrary angled walls and hence uses different method. Though you can use raycasting to get better results (DN3D like) but it requieres that all walls are lines and that the map is in sectors (closed rooms so you dont have to cast the ray so far). Intersecting planes calculations.....

Doom:

Im just curious, the way you describe the render process it sounds like it doesnt create correct view. Ceeping track of what columns has been rendered and if not draw next Nerest! ??... if it had said "furthest" I could agree =) ...You can draw either in "painters order" start from furthest away and draw closer to player (drawing over any previously drawn) or the better way, near to far, keeping track of what have been drawn and draw more, further away, if some columns isn't drawn...

(or am i missing something?)

Perhapps you speak of distance in BSP trees.... or something.... (im not that into gardening u know =)

Anyhow it is interesting... more so when you trye to fit all of that into 4Kb of memory! =)

February 1, 2003

Forgive me for asking, but are you shure Doom is 4Mb?

When I was surching for a "scrap" cart for my BJL i thought to get a 4Mb card incase I whanted to do some experiments later on (and get all addr.lines)

Thinking, or assuming, that Doom was 4Mb i got such.

Now. having it opened in my hand I see only 2 memory chips... 42 pins each. Numbers: 700529-002 and 700629-002.

Had they invented so big OTP eproms in those days? =) or is it realy 2Mb?

Im just curious and would like to know...

(if it is 2Mb im a bit amazed how they fit everything in it).

February 1, 2003

Please dont think that I post just to be a "smarta$$" =) I post in the quest for knowledge... or something =)

Anyhow to trye to clear up the jungle a bit:

Raycasting:

the player "casts" a "ray" for every column of the screen (f.ex. 320 rays) and checks if that ray intersects with anything (in a map/world). ...the "Gandalf" method =) Where he casts 320 spells... (OK bad resemblence! =)

RayTracing:

You follow, or "trace" a ray emenating from each pixel on the screen (ie for example 320*200) and checks what things it reflects against, at what angle, color, material properties, if that lightray has enough intensity to reflect in another objects, and so on... extremely time consuming and nothing for realtime gameplay.

PreRender Thigies:

A way to "cheat" so it looks like RayTracing is done. Actually it is just a picture that has been rendered in advance. Limiting the freedom of movement of the object.

1&3 is well suited for the jaguar =) 3 mostly for CDrom games since it needs a bit of memory.

This has nothing to do with the original post =) but cheating good will make a game look "flashier" and more up to date... if that can be connected with more bits then so be it =)

January 31, 2003

One of the main problems with porting falcon code (Bad Mood) is just what was the falcons "main advantage", It has 14Mb of memory! Even if it is made to run on standard falcons (4Mb) it is still 2 times the amount you have in the jaguar. It allso has harddrive suport and can load and repack stuff from the 14Mb PC wad file.

Now if you plan to do that for the jag... hmmm... I mean you might end up (like ID did) remaking the hole wad, removing stuff from the BSP tree, and redusing size, amount of grafics, since the jag only have 2Mb, in total.

And if you are going to redo everything... then why not do a new game from scratch! (So people will not complain how it looks agains their PS/GBA/X whatever ;o).

Another thing is that, Yes the code is quite 030, and the 030 is 3 generations better than 68k. So a straight port from 030 -> 68k code could be slow... even though the 030 is 16MHz and the 68k is 13.3MHz (you might think the clk speed is almost similar and hence almost same speed) But the 030 has cache! something that is extremely useful for speed.

But the main cpu use in that code is the DSP engine that computes everything.. and the jags DSP & the M56001 that is in the falcon is so NONsimilar that you still had to redo EVERYthing! (not mentioning that you first have to learn m56k1 asm, a GREAT idea! =) but perhapps not what you whant). It allso has a hole bunch of more memory than the jaguar (but it allso has 50 billion times slower bus than the jaguar, so they might even out =)

Anyhow, The idea is nice! But as i tryed to say before, I beleive it would be easier to trye to convert a general, non HW specific code to asm then to convert&revrite any hw specific code. This way you can figureout how to the jags HW to its fullest potential, right from the beginning.

/Sym

January 29, 2003

Some thoughts about engines:

If you start to look closely on the source avaiable you will soon see that it is not just a walk in the park to convert the code. Atleast not if you aim for speed (which I beleive is of most importence). And so would the "Blitz" people also have found out IF they had even read the jag specs, even more if they tried converting it.

Just making a straight port would have made the enginespecs on that link 20 times slower, than compared with a 486!

BUT! if the code can me handcarved to fit the jaguar then it would be much faster! ...But then the code is so much rewritten that any optimized PC asm fitted to a 256color graficscard, is so way of that only the "pseudocode" is similar. Any 5pages asm code is just hard to read!

That is why it would be easier to have a pure ansi C code that was slow as buck because it realtime calculated the shading for each pixel, But on the jaguar you just change that routine to change the intensityvalue in a CRY pixel...

Easiest if ALL C code was written in integer fixedpoint math it would be easier..

Ahhh i dont know if anything of this makes any sence, but I know that just porting any C code, isnt that easy. Especially if the code NEEDS doubles & floats to run (and menny of them do!).

It becomes so much harder when you in essence only have signed 16bit integers, 4Kb of cpu memory, and NO stack! (that all c codes use!)...

Anyhow.. the idea is nice! =) and i urge people to trye!

/Sym

January 29, 2003

Yes that helped! ;o)

Its Crystal Clear now =D

Sincerely:

I had hoped that there would be a 20% speedincrease using 256 width instead of 320. But as you said, there isnt :/

(though in theory it Should be! atleast in available bus access)

Cool though that such megahigh Xresolution can be made =) Could be used for some "HDTV" menues =) (1cart just to store the meny =)

What i lack is the "dbl line" thing that was on the jaguar. So that halfed Yres could be made. But It can be simulated by having a scalable bitmap and set Yscale to 0.5 But that doenst increase speed, rather slow it down...

/Sym

January 27, 2003

AvP 2 I would say.... if i couldnt do a totally new game, not existig on any other console/computer in the hole world, making it unique for the jag.

ps. The tech specs about the jaguar in your .pdf file makes absolutely no sence. An update from the dev.man could perhapps be a nice idea ds.

January 26, 2003

Do i understand correct if you have an atari computer that you upload with?

And you use the BJL program "ULP.tos" os something?

No it doesnt take .cof files... (and here comes some "guessing" but i think you need to be careful about .cof's they usually contain more info than the BJL can take. Usually info that the alphine boards debugger is suposed to handle (full lable names, and so on). You need a "100%" binary and compiled for startaddr $4000. Cof's for alphine is compiled to start at $802000 (i think =) and they will never work on bjl.

Im not realy shure, but i think BJL handles some version of .JAG and uploads correctly.

But.. MOST important about ST upl.tos is that it contains a minor BUG that will inhibit it from uploading some files (like SlamRacer). And there is no real solution to that (since there is only one uploader prg, so far)... I tried (perhapps not hard enough) to get hold of the upl source to fix it (and add other extremely useful features if you are a coder) but i never got any replye on that email...

If you dont find any solution to this problem and consider changing to shitwindows just to see slamracer, then mail me so I can "convince" you to Stay Atari! =)

Hope you get it to work! And may your BJL'd jag bring you much joy! =)

/Sym

January 26, 2003

What i ment was that the source could help showing the "tricks" they used to make texmaping so fast (what is OP, what is blitter, sprite masks? and so on).

Because i remember reading that they used quite allot of HW tricks to get it fast (ST Format, some number).

Thats what i would use the source for! ...and this is what i mean about "reinventing weels" You spend 2 months coding your "paper idea" just to come to the conclusion that it is to slow, and then you must rewrite everything, doing thigs different! ...instead of learning from them (knowing the result) and building your "paper theory" around that....

Just hints like "make edgebuffer in gpu ram", "swapp rest of code with blitter", "AI & sound in dsp", "use irq on dsp", and so on.....you get the idea...

DOOM source: IF the doom source is just a compilation of the PC/linux source, and the moded GNU C compiler "did all the work" then I am Not interested in the source, Then I would rater trye to make an ASM optimized version from scratch!

But! ...as with ALL coding on BJL (with extremely limited debug options) it is a good idea to have the algorithm working already, so you dont have to debug the algo first!. That is why it is easier to do if you have for example a working C source to convert to asm. Even easier if the C code is already made in fixpoint arithmetic..... then it is almost a straight "copywork" to port C code.

/Sym

January 26, 2003

I for one would allso verry VERRY much like to have the jag doom source. I have been trying to get it since it was first mentioned (atleast some years ago). I even tried to get hold of Carmack but that is harder than to talk to god himself! There is no email on their homepage only a html fill in form about "what do you whant to ask about Quake3?" or so...

Closest i got was the email given by Carmack in the Linux source release where he explained a bit about the source. But I never got any replye (and if he even got the email, i understand him, its just to far in the past to bother).

IF it is open source and IF someone has it (and isn't to greedy to hold on to it) then please spread it! Think it would inspiere ALLOT ! and increase the chanses of a running game (just add different wad support and you have heretic,hexen,.... Old games, yes, but new on the jag!).

It would also help developers to see how they solved the problems (that DO arise when coding the jaguar, especially if you aim for speed) so that they dont have to waste time on "reinventing the weel".

Just a last note aboute Doom==texturemapping;

I thought texturemapping was a way of asigning screen pixels colorvalues from a premade bitmap. And that it didnt matter in which way the maping was made (horisontal=polygon, vertical="doom") Just that they use to different methods to find the starting texels (polygon=scanconversion, doom=raycasting)

I would say doom is "texturemapped" all over... in an "affine" way =) (ie a linearely stretch of one strip (column) of bitmap.. that btw can be done in "hardware" by the jaguar blitter! (just that it has to work in pixelmode to draw vertical strips. In gouroud it draws horisontaly and then phrase mode can be used which is Sooooo much faster!).

Ahh well... "where were I, a weel needs a tyre does it not?" ... ;o)

/Sym

January 24, 2003

Hi!

The thought is nice, but i think that the problem is worse than you think. Several people with quite high tech skills have tried with not that suxessful results (or so i assume otherwise there would be a "Jag-accelerator" out there to buy).

If you still choose to operate on your jag (why!?) then i urge you to study the technical part of the dev.manual so you get a feeling for what is going on, studying the pinouts of tom & jerry in specific.

I beleive last time i heard people talk about this it ended like this (and if i know them right I will be corrected if im wrong =)

The jag uses one cklock only, and it is at pixel speed (pal or ntsc) this cklock is fed to jerry and In jerry halved and fed to the 68k (there goes your plan to bypass it!) Jerry feds the cklock to tom and the video curquit.

It also uses this clock for audio generation, everything!

So, if you just exchange the cklock for a faster one, it will effect the HOLE system! video will be out of sync (you need a special multisync monitor to even see the picture) audio will be wrong, and at to high speeds the memory will be to slow so everything will crash! If (i say IF!) you get it to work then the audio will sound like ...the smurfs or something =)

What i am saying, is that there is no idea in "reinventing the weel" or even destroying your jaguar. Read what other people have done and learn from their progress/failurs and trye to take a step forward. If you cant its better to ceep it as it is, play on it, and do resurch on better ideas! =)

Here is one:

Install menny more clocks! cut specific lines between the chips and hardware wiere different clocks between the chips. 1 to the DSP (it needs standard clock or the audio will be wrong) but TOM, OP, 68k could have faster clocks. Insert a hole bunch if sync stabilizers (at the right place) to get corrects sync (using your logic analyzer!) Worst case install faster memory! a huge heat sinc + fan and .... and.... and...

What ever you do... God luck! =)

Personally I sugest you to install a BJL instead and start coding, optimizing code is the best way to make the jaguar faster! =)

Cheers!

January 24, 2003

Just thought that since when the UK jag scene got so menny replyes, and france none (though you already are a step a head and having the party now!) I thought to say:

Viva La France! =)

Especially the Atari people! =)

..hope you guys have a nice time and discover menny new sides of the jaguar! =)

Wish I could be there !

/Sym

January 16, 2003

Looking forward to that scan & that read about AvP.

Allways thought AvP was a "wolfenstein with floors" and i guess my assumption was right =) ..Just they use (apparently RBG "trucolors" instead. Or perhapps they use CRY to get easy shading (if there is shading in avp think there is but it shouldnt be.. since there are huge (verry scary/reallike (cant describe it =) looking lights in the roof =)

But that article explains it. They use the blitter in increment mode to scale a vertical strip of the wall bitmap (like wolfenstein). Cool... =)

Now If i just could figure out how they did the floor I would be even happier =) ...this is a bit worse than drawin walls since you cant use the blitter in an easy way (Darn it! Who whants to have a mask register for A2 when all things you ever whanted to do needs a mask for A1 !!! =)

Ahh well... nice historical information anyway =)

/Sym

January 14, 2003

Speaking of 3ds2jag.

Can someone tell me if that program is compatible with new 3dstudio max, or any "recent" modelling program I would be happy. (And if it only works with old dos 3dstudio then so be it, just need to find that old program then =)

And If someone has the source code for the 3ds2jag converter PLEASE send it to me! It sais in the devman that if you whant it you should contact atari dev department... ok.. I'll do that

Why? well if someone whants to have a different datastructure that atari predefined it, Im stuck to editing a textfile

Thanx for any hints!

/Sym

January 14, 2003

Just a note... my ascii smileys does NOT lite this forum, they turn into something completely different.

I know, I know, im a beginner to this "high tech" forum (equals to, right paranthesis).

No Its Lunch time, Im outahere!

/Sym

January 14, 2003

Who Am I ? ...(thats a Jackie Chan movie btw =0)

Lets just say I have ca 10 years of assembler experience and that I have been here forever... waiting for serious diskussions ;o)

Programm atari for fun. Finaly found my system when I started jaguar some 2 years ago, on and off, as a hobby. And that is what it will remain... if it leads to a game Im happy if it dont, Im still happy because nothing beats coding assembler =) (this is my replye to Tyrant ;o) Once you go Assembler u never go back =)

2 Thunderbird:

Thanxfor the tipps. Some thoughts about them:

1) God I wish A1_Clip could work! but i tried that and when a gouroud line starts before left border the hole line turns black ! (?) like biinc isnt added to p_data ? When poly goes out on the right there seem to be a flicker consistent with Bug# ..? god knows, but it clippes some phrases to soon... Anyhow thats why I aimed for software clipping. And heres the story about that:

The rout is a "optimized" 3Edge rout, opti in the senze that when you have 3 points they always lie in a plane and parameters is constant over the surface. Now clipping... Humm.. i thought that i could use the "parrallellism" of the jaguar and that would not hurt the system that much. Ie while the blitter is blitting the previous scanline the gpu process&clips the next one. In theory it sounded nice =) Guess i have to reconsider (but 1st I'll kill waitstates). Because i still beleive that it should work. With all that "dead setuptime" the blitter has + blitting time, should be enough time for the gpu 2 clipp 3 values!!

2nd thing is that clipping that poly theoretically correct (SH algo, or whatever) on the left edge isnt that trivial (or is my brain dead?) Since a 3edge can become 5edge (more?) and i dont whant to start coding a N-edge case :/ Any ideas?

2) In gouroud it uses phraes as often as possible! I think. except when line is shorter than 31 pixels then switching to pixelmode makes the blitt faster due to less setuptime.

Also when colorgradient is to big for phrasemode, pixelmode is used. Hopefullt that doesnt hapen that often. Depends if the polys start on a dark color or not. And that should only happen on the edges (if light sorce is head on =)

4) Hmm.. yes.. So i have heard (Hi cts ;o) I know i should stop it, but how? ..in the st one could write "Stop 2700" or "2300" and it stopped dead in the water. but what to write on the jaguar? Is it the same? (remember trying it and the instructions after defenitely got executed).

3)

Yes I thought about this... but it just messes upp my brain when i think about it =) if i have to interleave first 2 framebuffers and then t-map data allso ...Arrgghh!

This brings me to texture "cache".

I tried having the tmap in dspram thought it would speed thing up having the bitmap in sram, but what happened? ...speedwise ...well slight increase but not 50% as hoped (like 10% perhapps) BUT worst was that the data got corrupted!!

Seems like INC mode doesnt work properly from dsp memory, why? (is it because 16bit bus to dsp?, but it shouldnt matter since INC mode fetches 1pixel at a time). Dissapointed was I :o/

Next question: if blitter is using dram the gpu can work in parallell in its sram right?! ..Now assume that there is enough space in gpuram to store a texturemap (the chalange to code on the jaguar optimize both for space and speed! =) Now if the blitter is blitting texturedata from sram -> dram will the gpu be able to execute code in parallell? ...(i dont think so, since it isnt "dualport sram" or something). And will blitter acessspeed to sram memory be 25MHz and to dram slower? (meaning atleast one fetch is fast while the write is slow).

(But if this inhibits the gpu to run in parallell with the blitt, it is not the way to go).

Still beleive that my "semi-phrase" texturemapper ide could work.. =) just that it requieres that i rewrite everything! ( (will not tell more untill I test it, If it works like i think it will I'll get it copyrighted ;o)

(This feels a bit lite "reinventing the weel" here, I "waste" 1/2 months on coding just to see that it isnt fast enough, comes upp with a better idea and back to scratch... Yes yes I know.. I said i am coding for the fun of it, so Im not complaining! =)

Thast it. (once again sorry for the kb's of ascii }

regards

/Sym

Sign In

Profiles

Member Map

Forums

Blogs

Gallery

Calendar

Store

Posts posted by Symmetry of TNG