How about a Commodore 64, a 1541 (or similar) disk drive, a copy of the original manual and, of course, a copy of the C64 Programmer's Reference Guide.....?
It can be easier to get going with only the bare basics of a computer, it's a simple enough system that a young teen (ok,..got a few years to go) can understand the/whole/ system inside their head.
Start with Basic, move onto Assembly language when you run out of power (or get very bored with Basic).
With a C64 you'll soon also be messing with hardware registers and stuff too (POKE is just about the only way to do anything at all - even change the border colour, etc) - you'll learn boolean operations when you need to peek/poke to set a bit, and that'll also get you into binary and hexadecimal too.
The same could apply to other old 8 or 16 bit home computers too, but my favourite was the '64.
The lessons learnt from hacking such a machine are invaluable if you're gonna try to program a game.
My view is at least somewhat biased: I was a professional games programmer for ~10 years, mostly on the C64 in the early days.
On the other hand, if 'making' games is the goal (as opposed to programming them), maybe you should look for some kind of 'construction kit' type software, or look at using a high level language and some decent library code -- I've got no real advice to offer on either of these though, sorry.
It's worth pointing out that in the UK we call 'em "bum bags" -- as the word 'fanny' is slang for that part of the anatomy that is particular to only the female of the species.
Nah... triple buffering is totally and utterly quick! (as long as you've got enough video memory to perform the necessary operations) -- and the code isn't that complex (or shouldn't be if you do it right!)
There should be negligible (dare I say zero?) performance hit if you use it on your primary visible surface -- triple buffering isn't for the individual windows, it'd be used only for the surface you composite your main onscreen view onto.
The overhead from executing code to achieve (triple) buffering is/really/ small: you are really only executing (1) the logic described in my last post (to keep track of in use buffers, and s/w locking them, etc), (2) a little interrupt handling (hey! we're now in the offscreen period!) and (3) some h/w access (method to switch visible surface: flip or blt)
Also, you start to gain performance from using back buffers because you avoid hardware memory locking issues. If you only have a primary buffer to draw to, with every 'blit' that takes place the hardware has to be available (not processing another request), and the destination memory must not be in use by any other hardware operation (reading RGB pixel array of visible surface to convert into a video signal).
By ensuring you are writing/modifying an offscreen surface you always ensure that the memory you are accessing is not in use by the video h/w.
The back buffer should, in theory (esp. in triple buffering) be completely free for you to do as you wish with -- free of any h/w locking through memory accesses, etc. -- and there should always be a surface freely available so when you say 'can I have a surface to draw on please?' there is no wait for a surface to unlock.
Obviously, some of the above issues may not be issues with some of the memory types fitted to very modern PC graphics cards (modern and trendy double dma, 0ws, doo-diddly-dangle super-vram), but I believe they still come into play on a lot of common PC video hardware that people use. It depends on the exact video chip / memory/etc (heh, if you're writing for the PC you have more variations to take into account, you'll end up using double/triple buffering if you want speed and a clean redraw - the API is easy to work with, no matter what's underneath).
Nowadays things are also made a bit easier as most of the modern video cards have a proper vblank interrupt -- obviously, some h/w doesn't support such a thing, in which case you'll have a hard job getting rid of the ugly shearing you describe (but using a back buffer will still make the refresh/cleaner/, and it should also be quicker due to the above points).
Most fullscreen/games APIs that I've worked with (on both sides) have allowed double/triple buffering, it's fairly common.
In any extremely rare cases (of h/w) where triple buffering does not improve performance, the loss (through added code execution) should be sooo small as to be totally insignificant -- and you've still gained a cleaner screen update as a result.
Oh yeah... triple buffering will only work as intended (ie: at full speed) if you have all (3) of the surfaces in video ram. If you can't/don't then there/will/ be a performance hit of some kind (somewhere on the system) when you flip (or shortly after).
And, by the way, no matter how fast your graphics updates are, you will always get shearing on a CRT, unless you blast your updates while the electron gun is returning to the top corner. I imagine that would add a great deal of complexity to the windowing system
Actually, this is isn't correct -- having spent too many years programming video games in the 80s-90s, I'll have a shot at explaining...
You fix the problem of onscreen redraw glitches simply by using double (or triple) buffering - all updates are then drawn to an off-screen back-buffer instead of to the visible surface, and once the back-buffer update is complete you wait until the next vsync (when the CRT is in an offscreen period) and 'flip' the visible surface out, bringing the newly drawn one into view.
Double buffering is simpler to code than triple buffering, but any system implementing either of these will still have a pretty simple API to call, and both will be similar (if not identical if you plan correctly) -- the tricky stuff all happens 'behind the scenes', usually implemented with a combination of interrupts, threads and code to handle 'surface locking'.
The 'cost' of using double buffering is: you need video memory for both a primary and a secondary surface, you have to write a small piece of (fairly technical) code -- and when you call flipSurfaces() no code can access a visible surface to draw upon until the 'flip' has actually taken place (the next VBlank interrupt), which will likely mean waiting code... tidy screen redraws, but stalling code.:(
If you have enough video memory, you can get around this 'waiting' problem by using triple buffering. It's a bit trickier to implement, and requires three times more memory than an unbuffered display - but you avoid the problem of having a locked back buffer (waiting to become the primary surface) by having the extra (and therefore always 'unlocked') surface ready to return when any code calls getBackBuffer().
When flipping screens (during the CRT gun's offscreen period), the new buffer can be made visible by either copying it to the front buffer (maybe using blt h/w, if available), or by changing some kind of magic memory pointer in the video hardware.
So stopping tearing can in fact be done fairly easily -- a heck of a lot of video games use a double or triple buffering, and have done since at least the early eighties. I don't think any of the PC Windowed-style OSes use this technique yet (...but I don't have a Mac, and with all that transparency and other eye candy I sure hope that they're drawing to an offscreen surface!)
(Sorry for the almost off topic ramble, but I had to satisfy my innermost geek)
..also worth noting that Google have recently introduce a very powerful implementation of word stemming. (Yup, this is separate to the synonyms, but is still related)
It's enabled by default - if you want exact match words (like it was a month ago) you need to search for: +keyword
Everyone keeps talking about the shit-key and Windows' autorun functionality, but when this thing runs it installs software -- is it still able to install itself if you are logged in as a user which doesn't have Administrator priviliges????
(Yeah, I know, it's a rare thing these days when a Windows user isn't a member of the Administrator group... especially a home user)
'Like a soccer ball' - kinda spherical??..as opposed to them funny shaped balls the americans use for 'football' (if i wasn't so ignorant, I'd call them rubgy balls)
Mail service is decoupled from Internet access for many users: hotmail/yahoo/etc (not that these webmail services are run by anyone more competent though)
Re:I still don't get cryptomoncomonmon
on
Quicksilver
·
· Score: 1
I actually considered not finishing it when I was about 20 pages from the end, and to this day, I wish I had.
Funny you say that, I stopped reading Diamond Age just before the ending because I was disappointed with the way that Snow Crash had just cut-off at the end, seemingly leaving many loose threads. To this day, I wish I had finished it!
FWIW, I did finish reading Cryptonomicon though, and thoroughly enjoyed it. Not everyone I know who tried reading it actually completed it though, so I do understand where you're coming from..
The only way I can see getting around this would be for Google to add "Did you mean 'apple' as a _fruit_, _computer company_, or _fiona apple_?" to the top of the listings, to drill down more specifically.
HotBot used to do exactly this, they were using the Cyc AI engine (from Cycorp) to do it. Read more about it here
People have been defecting from using Yahoo as their primary search engine for years, and they're not about to come back unless Yahoo can offer search results that are comparable to Google.
Yahoo's search results are (currently) provided by Google, and have been since 2000.
They've been outsourcing and not using their own technology since at least 1996.
JSPs are, behind the scenes, simply translated into Java source code and then compiled into classes by the Servlet/JSP engine.
Keeping complex code out of JSPs has little to do with runtime speed -- it's more about code maintenance issues (at the end of the day) than anything else.
cut the plants down, burn them, and kill those responsible for this madness - this kind of thing simply shouldn't be allowed to happen in a sane world!!;o)
Re:THAT'S considered an acceptible release bug???
on
Mozilla 1.4 RC1
·
· Score: 4, Funny
>> Maybe it's been fixed by the latest driver upgrade.
Yeah, the new drivers can detect if Mozilla is running, and if so run different code......
Slashdot Mirror
How about a Commodore 64, a 1541 (or similar) disk drive, a copy of the original manual and, of course, a copy of the C64 Programmer's Reference Guide.....?
..got a few years to go) can understand the /whole/ system inside their head.
It can be easier to get going with only the bare basics of a computer, it's a simple enough system that a young teen (ok,
Start with Basic, move onto Assembly language when you run out of power (or get very bored with Basic).
With a C64 you'll soon also be messing with hardware registers and stuff too (POKE is just about the only way to do anything at all - even change the border colour, etc) - you'll learn boolean operations when you need to peek/poke to set a bit, and that'll also get you into binary and hexadecimal too.
The same could apply to other old 8 or 16 bit home computers too, but my favourite was the '64.
The lessons learnt from hacking such a machine are invaluable if you're gonna try to program a game.
My view is at least somewhat biased: I was a professional games programmer for ~10 years, mostly on the C64 in the early days.
On the other hand, if 'making' games is the goal (as opposed to programming them), maybe you should look for some kind of 'construction kit' type software, or look at using a high level language and some decent library code -- I've got no real advice to offer on either of these though, sorry.
Good luck!
...but that doesn't tell you your externally visible IP, only the PCs local IP.
The whole of my intranet is private IPs, sitting behind one external public IP.
Sony have been making gadgets featuring their 'jog wheel' for a while now -- before Apple's iPods came out, I'm sure.
Having not used either Apple nor Sony's wheels, I don't know how they really compare -- are they the same thing? (they seem it to me)
if these vba excel macros don't work under open-office, then maybe running microsoft office/excel under wine would be a viable solution?
just a thought
It's worth pointing out that in the UK we call 'em "bum bags" -- as the word 'fanny' is slang for that part of the anatomy that is particular to only the female of the species.
[insert variant on obvious joke here..]
just stay away from the mountains!
Nah... triple buffering is totally and utterly quick! (as long as you've got enough video memory to perform the necessary operations) -- and the code isn't that complex (or shouldn't be if you do it right!)
/really/ small: you are really only executing (1) the logic described in my last post (to keep track of in use buffers, and s/w locking them, etc), (2) a little interrupt handling (hey! we're now in the offscreen period!) and (3) some h/w access (method to switch visible surface: flip or blt)
/etc (heh, if you're writing for the PC you have more variations to take into account, you'll end up using double/triple buffering if you want speed and a clean redraw - the API is easy to work with, no matter what's underneath).
/cleaner/, and it should also be quicker due to the above points).
/will/ be a performance hit of some kind (somewhere on the system) when you flip (or shortly after).
There should be negligible (dare I say zero?) performance hit if you use it on your primary visible surface -- triple buffering isn't for the individual windows, it'd be used only for the surface you composite your main onscreen view onto.
The overhead from executing code to achieve (triple) buffering is
Also, you start to gain performance from using back buffers because you avoid hardware memory locking issues. If you only have a primary buffer to draw to, with every 'blit' that takes place the hardware has to be available (not processing another request), and the destination memory must not be in use by any other hardware operation (reading RGB pixel array of visible surface to convert into a video signal).
By ensuring you are writing/modifying an offscreen surface you always ensure that the memory you are accessing is not in use by the video h/w.
The back buffer should, in theory (esp. in triple buffering) be completely free for you to do as you wish with -- free of any h/w locking through memory accesses, etc. -- and there should always be a surface freely available so when you say 'can I have a surface to draw on please?' there is no wait for a surface to unlock.
Obviously, some of the above issues may not be issues with some of the memory types fitted to very modern PC graphics cards (modern and trendy double dma, 0ws, doo-diddly-dangle super-vram), but I believe they still come into play on a lot of common PC video hardware that people use. It depends on the exact video chip / memory
Nowadays things are also made a bit easier as most of the modern video cards have a proper vblank interrupt -- obviously, some h/w doesn't support such a thing, in which case you'll have a hard job getting rid of the ugly shearing you describe (but using a back buffer will still make the refresh
Most fullscreen/games APIs that I've worked with (on both sides) have allowed double/triple buffering, it's fairly common.
In any extremely rare cases (of h/w) where triple buffering does not improve performance, the loss (through added code execution) should be sooo small as to be totally insignificant -- and you've still gained a cleaner screen update as a result.
Oh yeah... triple buffering will only work as intended (ie: at full speed) if you have all (3) of the surfaces in video ram. If you can't/don't then there
Actually, this is isn't correct -- having spent too many years programming video games in the 80s-90s, I'll have a shot at explaining...
You fix the problem of onscreen redraw glitches simply by using double (or triple) buffering - all updates are then drawn to an off-screen back-buffer instead of to the visible surface, and once the back-buffer update is complete you wait until the next vsync (when the CRT is in an offscreen period) and 'flip' the visible surface out, bringing the newly drawn one into view.
Double buffering is simpler to code than triple buffering, but any system implementing either of these will still have a pretty simple API to call, and both will be similar (if not identical if you plan correctly) -- the tricky stuff all happens 'behind the scenes', usually implemented with a combination of interrupts, threads and code to handle 'surface locking'.
The 'cost' of using double buffering is: you need video memory for both a primary and a secondary surface, you have to write a small piece of (fairly technical) code -- and when you call flipSurfaces() no code can access a visible surface to draw upon until the 'flip' has actually taken place (the next VBlank interrupt), which will likely mean waiting code... tidy screen redraws, but stalling code. :(
If you have enough video memory, you can get around this 'waiting' problem by using triple buffering. It's a bit trickier to implement, and requires three times more memory than an unbuffered display - but you avoid the problem of having a locked back buffer (waiting to become the primary surface) by having the extra (and therefore always 'unlocked') surface ready to return when any code calls getBackBuffer().
When flipping screens (during the CRT gun's offscreen period), the new buffer can be made visible by either copying it to the front buffer (maybe using blt h/w, if available), or by changing some kind of magic memory pointer in the video hardware.
So stopping tearing can in fact be done fairly easily -- a heck of a lot of video games use a double or triple buffering, and have done since at least the early eighties. I don't think any of the PC Windowed-style OSes use this technique yet (...but I don't have a Mac, and with all that transparency and other eye candy I sure hope that they're drawing to an offscreen surface!)
(Sorry for the almost off topic ramble, but I had to satisfy my innermost geek)
..also worth noting that Google have recently introduce a very powerful implementation of word stemming. (Yup, this is separate to the synonyms, but is still related)
It's enabled by default - if you want exact match words (like it was a month ago) you need to search for: +keyword
I believe there was a Hitch Hikers Guide done by Infocom, but I don't know if Adams was involved in it's production.
I remember enjoying the game quite a lot--but I was young at the time
ooops, that should be shift-key.
(..and I did use the 'preview' button. More than once in fact. doh!)
Everyone keeps talking about the shit-key and Windows' autorun functionality, but when this thing runs it installs software -- is it still able to install itself if you are logged in as a user which doesn't have Administrator priviliges????
(Yeah, I know, it's a rare thing these days when a Windows user isn't a member of the Administrator group... especially a home user)
'scuse me, I'm english.
..as opposed to them funny shaped balls the americans use for 'football' (if i wasn't so ignorant, I'd call them rubgy balls)
'Like a soccer ball' - kinda spherical??
Mail service is decoupled from Internet access for many users: hotmail/yahoo/etc (not that these webmail services are run by anyone more competent though)
Funny you say that, I stopped reading Diamond Age just before the ending because I was disappointed with the way that Snow Crash had just cut-off at the end, seemingly leaving many loose threads. To this day, I wish I had finished it!
FWIW, I did finish reading Cryptonomicon though, and thoroughly enjoyed it. Not everyone I know who tried reading it actually completed it though, so I do understand where you're coming from..
Cheers,
fRoGG
..only now it'll be as easy as clicking a checkbox -- or perhaps:
Clippy: Hi, I can see you're trying to [take over the world] -- would you like me to enable DRM?
HotBot used to do exactly this, they were using the Cyc AI engine (from Cycorp) to do it. Read more about it here
You don't need to do that: VNC has a Java client built-in, you can run it in any browser that has a half-decent Java VM (inc. Microsoft's).
To access this Java client, you simply have to point your browser to http://myserver.foo:5800/ ..and you're off!
hth
Yahoo's search results are (currently) provided by Google, and have been since 2000.
They've been outsourcing and not using their own technology since at least 1996.
More info can be found here
JSPs are, behind the scenes, simply translated into Java source code and then compiled into classes by the Servlet/JSP engine.
Keeping complex code out of JSPs has little to do with runtime speed -- it's more about code maintenance issues (at the end of the day) than anything else.
>>Scientists Grow Decaffeinated Coffee Plants
;o)
cut the plants down, burn them, and kill those responsible for this madness - this kind of thing simply shouldn't be allowed to happen in a sane world!!
>> Maybe it's been fixed by the latest driver upgrade.
Yeah, the new drivers can detect if Mozilla is running, and if so run different code......
I think I'll have to experiment a little more with the cooking time, as they seem a bit too crunchy for my liking - any suggestions?
Um, C doesn't have any exception handling - that only arrived with C++
I've found Ontrack's Easy Recovery to be one of the most useful hd recovery tools out there.