!hd also sim coupe didnt like the full screen or maybe it was camtasia i used to record the desktop anyone got a better one? anyone figure out how to use the tv encoder chip on the vga card - msi mx440 vtd 8x agp /ti4200 vtd 128 / fx5900 zt vtd 128 all msi all Video input video output - none support hi deff despite the manual claiming the tv encoder can encode mpeg with 600mhz proces...@1024x768 - dont seem too hi deff to me!
also ati x1950 power colour this had a component input cable with an arrow pointing towards teh machine but guess what also msi digital tv tuner - still only composite and s-video inputs although kind of weirdly the virgn/ntl set top box my brother has actually manages to get the screen to fill the pc tv tuner screen whereas the output from the box never quite works on the tv no matter what setting you try?! maybe use the lan/usb/serial/scart to conenct it to a hi deff tv? need to reflash the bios? not available from ntl/virgin also cant use the cable feed to get hi deff on the pc or the cable cahnnels or the internet have to have adpater for set top box and adapter for a router - was similar in hong kong luckily i had three fans in the card board box above the loos otherwise ida fryed! pccw 6mbps yeah sure engineer tested it never above 300kb and that would have been a miracle ohh you loose 5mbps when you are watching the digital tv service oh yeah well in that case youd have to be giveing me 5mbps in the first place before i could loose what you have never given me in the first place $150 a month christ! crooks can you use the itu t v44 320kbps modem at the same time would increase by 2½ the upload ability at the sneakily unadvertised 256kbps speed (fat chance!) 2009/8/19 Roger Jowett <rogerjow...@gmail.com>: > 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >
