http://www.youtube.com/watch?v=ALLAUaVoQC0&feature=channel_page
dunno if youd need a dma for this in mode1 or it'd b n e easier in mode2 will try mode 3 next then if anyone knows an easy to use interlace routine would the second interlaced screen be one pixel line below the first - is that how it works its alternate scan lines 2009/8/19 Roger Jowett <rogerjow...@gmail.com>: > but surely the code can be fed into the samc compiler no - sam vision > erm it looks close?! > are you sure that as teh filled in cube rotates it wouldnt be easier > to drop to mode1 couldnt you fill 64 pixels of colour witha single > byte attribute square only need to work out how many you could get > away with seems a bit jerk how many frames does it take to draw? > have you tried the echologia demo with the dma and mb-02+ in real > spectrum - not sure if they are using the dma tah much some models > take 3 to 7 frames to draw > wouldnt a sam dma be a wee bit faster than the quoted 17jb per frame > velesoft reckon the dma datagear interface handles in on128k > also do you need masterdos to detect an external sam - its only > another 3mhz but what about those register hungry emulators like the > apple and oric or whatever its called oreo - isnt that a biscuit? > did you catcht eh text font.... its taken me a loooong time > silver paint tonight pressure sensitive keyboard membrane here i come! > - didnt realise the 128keypad had a pic controller in it dont they go > up to 80mhz! theres development kits in maplin £44 or build it your > self for £25ish grade b=£20 > http://www.maplin.co.uk/Search.aspx?menuno=12483 > > usb... > > http://www.maplin.co.uk/Search.aspx?menuno=12545 > > > 2009/8/7 Simon Cooke <si...@popcornfilms.com>: >> It's still pretty much just a quick sin/cos lookup for the euler angle >> calculation. As you say, you just store it in a form that hits 0 at 0, and >> 2pi - epsilon at 65535. (Or something similar), and then just do a lookup. >> That part's fast. >> >> Quaternions... The biggest advantage is that you can interpolate between >> them - which is necessary for skeletal animation. There are a number of >> disadvantages though - the need to occasionally renormalize them being a big >> one. (You're not actually gaining any kind of stability there per se; all >> you're doing is trading one numerical inaccuracy for another). >> >> Here's a case against them: >> >> http://www.gamedev.net/reference/articles/article1199.asp >> http://www.somedude.net/gamemonkey/forum/viewtopic.php?f=12&t=380 >> >> >> http://www.sjbrown.co.uk/2002/05/01/quaternions/ >> >> Note: it may make sense to handle your camera as a quaternion, vs. a >> rotation matrix for local->worldspace transforms, based on the cost of >> operations. >> >> If you decompose your matrix into all of the pieces you need to calculate >> when you build it, and keep that alongside all of the pieces you need to >> apply when you apply it, then you might find more optimization opportunities >> - especially if you're not performing more than one rotation at once. >> >> But ultimately, the name of the game here is to go as far as possible, so >> it's all going to come down to your use cases. >> >> >> >> >> -----Original Message----- >> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >> Behalf Of Thomas Harte >> Sent: Wednesday, August 05, 2009 4:13 PM >> To: sam-users@nvg.ntnu.no >> Subject: Re: Hi - just checking >> >> They're in some format or another that I don't recall offhand, but is >> lined up so that a full circle is a nice round binary number for the >> obvious range fixing optimisation. But it's not just a quick sin/cos >> table lookup unless you're rotating around one axis only. See, e.g. >> http://www.manpagez.com/man/3/glRotatef/ (the man page for glRotatef) >> - clearly there's a lot more going on there than table lookups. >> >> Of course, I am taking note of coherences. If the angles associated >> with an object do not change from one frame to the next, the source >> matrix is not recalculated. This optimisation postdates the version of >> my code that has already appeared on Sam Revival, but predates the >> next version (which is a better optimised version of the code shown in >> my video http://www.youtube.com/watch?v=j0xN_Mi3B_I) >> >> As I've posted to this list in the past, I use something vaguely like >> SIMD to multiply a 2d vector by a scalar - the relevant part of the >> scalar sits in the accumulator and is shifted there to make the >> add/don't add decision in the standard binary multiplication formula, >> meanwhile the 2d vector sits with the work going in for one component >> occupying BC, DE and HL, the work for the other occupying BC', DE' and >> HL'. Hence I get a substantial saving on multiplying the two vector >> components by the scalar separately. >> >> Naturally, I have a classic y = f((x^2)/4) table for the limited range >> multiplications (related to the maximum size an individual object may >> be). >> >> I assume your point about not accumulating transformations in matrices >> effectively means that you agree that quaternions are useful beyond >> interpolation and animation (which I'm interpreting quite narrowly to >> be the traditional skeletal type, not broadly to be any old moving >> image). >> >> Anyway, hopefully I'll be able to get myself in gear for a source >> release at some point in the near future, then you can rip it apart. >> It's all geared up to be trivial for other (assembler) coders to use >> to produce their own programs, handling triple buffering and frame >> rate compensation with very limited need for work on the part of the >> programmer (which neatly means that all my code scales really well >> from a normal Sam to a Mayhem or otherwise accelerated machine), etc. >> I tidied most of it up for a release quite a while ago but decided to >> switch to Jam rather than sticking on pyz80 because a lot of stuff >> would be substantially more compact and more readable with proper >> macro support. I also would much rather that the demo was seen first >> on Sam Revival rather than on the internet, both as a pathetic attempt >> to support the publication and because it looks much better on a real >> television. Never found time to convert it though, so it'll be a pyz80 >> release. >> >> Actually, the demo on the previous Sam Revival was explicitly flagged >> as PD, so I'll upload a DSK of that demo somewhere once the next >> edition is out. I think I mentioned every Sam program I've written in >> the SR article; you can see most of them very briefly in >> http://www.youtube.com/watch?v=kr_Lz98qVjE&feature=channel_page >> >> On Wed, Aug 5, 2009 at 10:16 PM, Simon Cooke<si...@popcornfilms.com> wrote: >>> Hmmm... what form are you using your Eulers in? If it's radians, it's not >>> too bad - just a quick sin/cos table lookup. And you only need to do it >> once >>> per object if it's a simple rigid body. >>> >>> The trick with making matrices numerically stable is that you don't ever >>> want to do a stepwise transform on an object - you regenerate the matrix >>> from scratch each time. (This is one of those things you never really see >> in >>> practice; most engines split out the rotational transforms and keep them >>> separate, using either an axis-angle representation, quaternions, or in >> some >>> bad cases, euler angles [this is what Unreal uses btw]. That way, you keep >>> fidelity - or at the very least, you don't care too much about >> inaccuracies >>> as they come in - you can just ignore them if your object is rotated a >>> little off; it's not a culumlative error). >>> >>> Assuming no scaling or shear, just rotation and translation, your >>> translation is the rightmost column of numbers in the matrix. If all of >> your >>> objects are pre-scaled in memory to the right size, all you have to do is >>> apply the rotation and translation in order to each of the points. >>> Screen-space projection is a little more difficult, but that one you can >>> precalc all the divides in. >>> >>> On machines without SIMD or dedicated 3D instructions (such as the SAM), >>> it's nearly always best to break out the matrix into individual linear >>> equations, take the common pieces and only calculate them once, and then >>> operate on them that way. >>> >>> -- >>> Simon Cooke >>> Director of Engineering / Business Developer, X-RAY KID STUDIOS - >>> www.x-raykid.com >>> Founder, Popcorn Films - www.popcornfilms.com >>> Cell: 206 250 7892 XBOX Live GamerTag: Spec Tec >>> >>> -----Original Message----- >>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>> Behalf Of Thomas Harte >>> Sent: Wednesday, August 05, 2009 5:14 AM >>> To: sam-users@nvg.ntnu.no >>> Subject: Re: Hi - just checking >>> >>> That's not entirely true. Matrices are numerically unstable, so the >>> cost of ensuring they remain orthonormal when applying consecutive >>> local transforms in a game such as Elite is substantially greater than >>> the cost of ensuring that a quaternion remains of unit length. >>> >>> I make it 8 multiplies, 3 adds, 1 square root and 1 divide to fix up >>> numerical error in a quaternion. Conversely, I get 36 multiplies, 21 >>> adds, 3 square roots and 3 divides to fix up an orthonormal matrix. >>> >>> Quaternion to matrix is 10 multiplies, 6 shifts and 14 adds. So the >>> way I calculate it, you can fix a quaternion and convert it into a >>> matrix in less than you can fix up a matrix. Furthermore, quaternion >>> composition is 16 multiplies and 12 adds, whereas matrix composition >>> (with assumptions about the bottom row of a 4x4) is, ummm, at least 36 >>> multiplies and 18 adds. And that's with the translation component not >>> completely factored in (I'm reading actual code off screen and have >>> optimised the translation out of this particular batch). >>> >>> Elite is also a perfect example of when Euler's aren't fine, even if >>> they didn't produce Gimbal lock, as all rotation is around local axes. >>> And besides that, Euler angles always have to be converted to some >>> other form before they can be applied to arbitrary geometry. Matrices >>> require no further transforms. >>> >>> On Wed, Aug 5, 2009 at 2:12 AM, Simon Cooke<si...@popcornfilms.com> wrote: >>>> You only really need quaternions if you're doing animation or >>> interpolation. >>>> If you can live with the gimble lock, euler's fine. >>>> >>>> -----Original Message----- >>>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] On >>>> Behalf Of Thomas Harte >>>> Sent: Tuesday, August 04, 2009 10:05 AM >>>> To: sam-users@nvg.ntnu.no >>>> Subject: Re: Hi - just checking >>>> >>>> Am I replying to the correct thread? I don't know. But I've had the >>>> opposite experience to a bunch of people here, having become >>>> substantially more busy in my work than I was even just a few months >>>> ago, squeezing the SAM temporarily out. >>>> >>>> A version of my vector 3d-stuff-as-a-library-for-others was all but >>>> finished several months ago, I'll endeavour to get that out, though it >>>> still has the awkward limitation of doing rotations with Euler angles >>>> only - which may be less efficient and is certainly more limiting than >>>> special orthogonals or quaternions. >>>> >>>> I'm still thinking about smart ways to optimise the reverse face >>>> stuff. I need to get something hierarchical or otherwise group-related >>>> in there; checking every single face is obviously not the optimal way >>>> to proceed. I guess what I'm looking for is some sort of bin-type >>>> mapping to the surface of the unit sphere that allows all the points >>>> on a particular hemisphere to be isolated from the majority of the >>>> points on the opposite hemisphere. Or, you know, something at least a >>>> lot like a sphere. Though I'm not sure any sort of lookup into >>>> something a lot like a sphere would help much as it'd need to be >>>> indexed by a three-tuple. >>>> >>>> I guess a good broad sweep would be to mark each face according to the >>>> visibility of the faces of a bounding box - if a face on the real >>>> model points away from the face on the bounding box then it definitely >>>> can't be visible if the box face is. Or something like that. >>>> >>>> I'm going to stop thinking aloud now... >>>> >>>> On Tue, Aug 4, 2009 at 10:22 AM, Steve Parry-Thomas<morriga...@aol.com> >>>> wrote: >>>>> I guess when the clocks go back in October SAM users will hibernate over >>>> the >>>>> winter until next August! >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> From: owner-sam-us...@nvg.ntnu.no [mailto:owner-sam-us...@nvg.ntnu.no] >> On >>>>> Behalf Of Ian Spencer >>>>> Sent: 04 August 2009 08:04 >>>>> >>>>> To: sam-users@nvg.ntnu.no >>>>> Subject: Re: Hi - just checking >>>>> >>>>> >>>>> >>>>> Wow, I just sent the checking mail to see whether something was wrong >>> with >>>>> my subscription to the group and it seems it was like poking a stick >> into >>>> a >>>>> hornets nest (in a positive sort of way) - over 40 mails in the last few >>>>> days on the group. It's just great to see everyone is alive and kicking >>>> out >>>>> there. >>>>> >>>>> >>>>> >>>>> Ian >>>>> >>>>> >>>>> >>>>> ----- Original Message ----- >>>>> >>>>> From: Ian Spencer >>>>> >>>>> To: sam-users@nvg.ntnu.no >>>>> >>>>> Sent: Friday, July 31, 2009 4:10 PM >>>>> >>>>> Subject: Hi - just checking >>>>> >>>>> >>>>> >>>>> Not heard anything on the group for quite a while so just thought I >> would >>>>> send a 'test' to check it's not me that's got a problem and say hi to >>>>> everyone. >>>>> >>>>> I know you've all taken your Sam's to the beach and so no activity on >> the >>>>> group. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Ian >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >
