Symmetry of TNG

Finally!... Seb you are the Man! =) *wiping happy tears*

Thanx Everyone!... your greets mean more than you know! Group Hug, come on =) in a straight, hentrosexual way =) GT just got an idea, publish it later as a book ... =) ...name it "asm romance" and put it under surrealistic art and it will sell in millions Thanx 2u all! /Symmetry Yet another revoultion around the sun older... Man I'm geting dizzy!

I starred at that coolest cake ever for a hole day so I missed to say: GRATTIS PÅ FÖDELSEDAGEN GT! =) Keep those 25K lines growing! cheers! /Sym

Asshoot... though I commented on this =) This is just great work man!.. I never got the GPU debugger option to work with my alpine.. so always debugged code in my head. Now i can use it for something else =) I hope work on this will be continued it is a verry useful tool. THANK Y-O-U! Orion & coworkers for beeing the F-I-R-S-T one to release such a Great! tool for the jaguar scene! /Sym

Amen to that! Merry XMas & happy newYear to everyone! Hope 2k8 will be a fruitfull year for the Jaguar! /Sym

"Ha den Äran!" =) Hope you got a big Jaguar 3D preesnt this year so you dont have to make one yourself ;D ...but ohh.. wait.. you just might have to do just that ;P Happy B day man! /Symmetry ....(from Sweden)

>and the connections are made using inexpensive and easy to find audio cables (no hubs/switches are needed). on the other hand Hubs/switches & TP cable are almost a standard today and cabling are most probably already done in a house.. And having a Ethernet connection & perhapps some day an online gaming would open new doors for jag fans.. (that cant go to rgc/jagfiest for a quick game with a friend...could easily game online with them...) There are actually werry neat, already made things, for "cabled ethernet network" ... ...I need to PM SPCD.. Anyway nice to see progress! =) (though i didnt understand that Spy thing... (is it for eavesdropping on communication? isnt that just a debugtool? or is it actually usable for something usable?) cheers /Sym

Nice!... =) So.. you are saying that its slower to copy data FROM gpu mem 2 dram (5632) than it is to copy TO gou mem(3584)? Any ideas why? I dont realy understand that from a logical point of view.. ? ..does the DRAM timings differ in read vs write? ...sram should have same read & write time right? ..how about dram? or is it an OP stall, page miss on writes to dram or what? why is it slower to copy TO dram than it is to copy from it? What are the GPU dooing in your example code? ...Im just curious because I have always wondered what happens when you start a GPU->dram blitt and continue running GPU code afterwards... I mean logically someone would have to halt to give the blitter acceess to gpumem right?... ie a gpu2-dram blitt would halt gpu exec and parallelism would be lost, or? Can this be verified with your LA? ....ie faster blitts from gpumem if gpu is turned off. (or perhapps its just a stall issue, once the blitt start it finishes in same time?!) Its nice to see that the +$8000 is realy faster, because in my experiments (iirc the tunnel code) It had no effect at all.. not something that could be seen in fps count anyway.. (or "raster bar timings", they were same size). Last question: When i did my own timing test of the memory (simple color "rasters" on screen) the DRAM->DRAM blitt code was As Fast as anything that had to do with the GPU memory!... I assume src&desr was within the same Page in dram hence the speed.. But it would be nice to se such a timing... ie blitter phrase blitt of dram->dram, preferabely within the same page. ...well offcourse it would be nice to see what happens if blitt crosses page boundary so there will be a page miss on each phrase.. (then perhapps we will se my point on why cleverly written GPU sdram code would be faster than the "running from main ram" thingy.. Perhapps this is because dram->dram will be true 64bits, while dram->gpumem would have to be 2*32bits.. Ie keeping the page boundaries in mind when you design your code will give you the ultimate power of the jaguar!. sorry for all question, but timing issues are interesting from an optimisation point of view Nice work! cheers /Sym

Nice Price! & nice Pic Just cant wait for a JagCF Demo "HD Ready"

Thank you all verry much! Sorry for not beeing online so much atm.. I'm finding myself building electronics equipment in my free time... dont know who spured that interest? spcd? zerosquare? ...guess you are both "guilty" ..well it is for a good cause so I guess i should thank you instead Thanx everyone! I honestly appresiate it! regards /Sym

Hmm a 3D related question out in the open.?.. ok fine by me One can debate forever if it is worth the HOLE lot of extra trouble it is to get pixel perfect polys and compare that to the extra polycount or framerate you get if you just accept some dropouts.. But i guess for a racing game it doesnt matter that much, but for a "Tomb raider" it might. (cf Ps1). So.. Bresenham.. when i sat down with it and did some comparisons if a line goes from upper right to down left in a polygon, the polygon that gets below it, its rout will fill over large portions of the already drawn upper poly!... ?... for flat polys this might not matter much, you will never get dropouts for sure, but for example if you use textures, you will loose allot of textures from upper poly when the lower one paints them over. What you need is a "Fill convention" ...you need to descide to have, for example, a "top-left" fill convention, where you "round up" your scanline startingposition on the top & left side of your poly, and round down on bottom& right. check out Chris Heckers article on Perspective Texturemapping at http://www.d6.com/users/checker/misctech.htm Havent realy checked my old rout with a lupe, but i think it looks rather ok (?) ..16.16 math it fits the blitter nicely (with its fractional pixelstart positions). it will automatically deside if the blitter should draw the pixel or not and handle the fraction->screen-integer-pixel-position truncation for you. Perhapps there is an easier way to do this altogether, if someone knows please let me know =) cheers /Sym

hmmm.. just looked at the cd encryption files from curts page http://www.atarimuseum.com/videogames/cons...enu/jagmenu.htm and from what you say it sounds pritty much straight forward... I need to test this... thanx for the wakeupcall Matthias =P

hmm.. anyone feel up for the task of making an "alpine version"? ...I would like to have such a working environment. since I dont want to mix dev env to much. Last time i tried this i ended up partially re-wrighting some version of this code from the HQ cd.. doing this n that and the finally compiling version chewed on my test CD for hours.. then program crashed, Dooh! =) I admit it, Im ashamed of not having encryption working yet... =) ...but I always felt that "I always have Domins BJL version" =) ... Ahh well... now i have a cd version aswell odds are getting better n better every day cheers

and the fish shoots what exactly? sorry naughty naught me =P ... sincerely... multimedia fusion.. is there a runnable version somewhere? animation says more than a 1000nd screenshots =) I beleive any game would be nice on the jaguar ..so... start learning to code ;P cheers

actually I beleive this to be nice work man =) Though last time I looked at encryption i ended up trying to get the encryption src (version unknown?) to compile, since I never saw the "true" atari dev kit program available somewhere, ie one that use the alpine setup. Having an alpine thats the code i'd prefer to use (not to mix up to meny dev env's). and afaik you always released bjl versions? ....do you have a working alpine version? (then i'd be verry interested =) but as before as a last resort I always have your bjl prgs as a way out =) ...and now i have, yet another, (better?!) tool to do it =) thanx /Sym