Are you trying to make a point with sarcasm? If so, I have to point out, that's neither how real keys nor software keys work. If you're caught, you're in trouble either way.
Why has nobody mentioned the obvious analogy? It's a "key" for crying out loud. Losing it is "like" losing a key. If you lose the key to your house or car, you just get another. OTOH, you do still have to prove that you own it some other way. Can software registration records be used for this purpose?
Clearly there's something that can be gained if they managed to get an additional 30% of lossless compression out of the existing JPEG format. My point is that if they had opened up the possibility of changing the JPEG format itself rather than developing lossless compression on top of it, they might have been able to do even better. I don't know how I can make it any more clear... perhaps like this:
Assume they introduce the new SIF format which is internally a JPEG with the new compression applied on top of it.
Recognize that the SIF format gets *exactly* the same quality as JPEG with an average 30% reductionin size.
Conclude that formats better than JPEG do exist with a better compression/quality trade-off.
Hypothesize that an even better format could exist if the SIF format weren't based on two completely separate algorithms / formats internally but one integrated intelligent algorithm / format.
Like I said, with more effort, the results could probably be improved, but due to the way software is designed, it's not always as easy as it sounds to reach theoretical limits (10,000 records in 1 second) when taking into account other design considerations. Also, 10,000 records cannot be downloaded in 1 second when your remote system is using a modem, which many people still do from remote locations.
Reencoding them as you suggest would be equivalent to converting say an mp3 to ogg format - a surefire way to lose quality with little gain
I don't think that's what was being suggested. I think I know what was being suggested because the same thought occurred to me. Why not just improve the JPG format rather than invent a compression algorithm on top of it? The reason I would expect this to be better is the very same reason you state -- going through two separate conversions/formats is less efficient. Why not improve the JPG format itself rather than use the lossy JPG compression and then introduce a separate (lossless) compression on top of that? I would think that working directly on the JPG format would allow you to get a better quality-size value (more quality and/or smaller size). Introducing a lossless compression on top of JPG is interesting, but integrating something into the JPG algorithm that still allows for loss could probably get better results.
This may all sound funny (I'm guilty of thinking that as I read some of this too) but when I think about it and realize how real it is, it starts to scare me. Cars in particular are one situation where people go on auto-pilot and might react before thinking. We have a lot of stories about people who "almost" did things... I wonder if there have been real accidents that people don't dare share. And I wonder if the dangers increase as games become more realistic (a more realistic emergency brake controller for those who have mentioned using that, for example).
I think it's not entirely about being able to distinguish between reality and game, but also (or mainly) about switching your "autopilot" to react appropriately. Driving may be the most prevalent and severe case to deal with (just a guess). If you've been driving in a game all day, you have trained your autopilot to react in certain wayt to certain road circumstances. Obviously when you then go out on the road you consciously realize that you are in reality now, but I think your autopilot (which is used heavily during driving) doesn't care -- it just has a certain set of circumstances and reactions that it's been trained with. So if you're not consciously thinking about what you're doing, you may easily be inclined to react inappropriately to certain circumstances.
I played Tetris on the computers in the CS lab in college just a little too long/often and later found myself trying to figure out how writing on the blackboards during class could fit together.
I program for an international ERP software company, and one thing I notice in addressing such challenges is that the desire to centralize the data and yet provide remote access is the counterbalance to high performance. In MS Access, a long scrolling list of items would not be such a problem when you're working with a local database. But since the data needs to be centralized, and access to the system needs to be remote, ERP systems have to be designed in a way that can allow remote users to deal with a managably small amount of data at a time. Often times the lists you deal with in an ERP system are so large that it's not practical (for the user) to view the entire list anyway (even if performance is optimal), so a user will often times type in a part of a name to narrow down the list to the items they are interested in. But depending on where you strike a balance, performance results may vary greatly for long lists.
Not to defend Axapta (I haven't used it myself); it's just a relevant observation I have about designing ERP software. With enough time and effort, I would think one could do better in getting the best of both worlds (performance and remote access), but it does have to be intentional.
Well there appears to be some value in the idea because, at least for a while, thinkgeek.com was selling them. They're just not as cheap as you might want, but they are certainly cheaper than $6000.
I made a program that can actually use RSA for encrypting a whole file/message (based on base 256, base 64 and base 10 conversions of RSA transformations on huge numbers). Is is kinda slow with larger key sizes, but not intolerable. And it allows quite large keys (larger than 1024 bit).
I think the biggest challenge facing humanity right now is energy. I don't know if everyone realizes how many of the world's problems are based on energy consumption and how much better off we would be with some alternative energy source that is safe, clean, cheap and plentiful. Surely we've put our minds to it before, and maybe it's futile to hope for such a miracle, but maybe it's time to try again. Any hope of finally getting that cold fusion to work?:) Or maybe some combination of high yield solar panels with efficient storage cells.
Imagine -- forget mideast oil and all their conflicts; forget pollution -- most of it comes from our current, primary energy sources; forget nuclear waste disposal (after we're done with what we've already got to deal with); and if the energy source is reasonably self-contained / localized (like solar panels on the house), forget transmission problems and dangers. If I had to pay double taxes for 2 years to get this worked out, I'd be all for it!
What about the budding game programmer's favorite? JavaScript and the general browser object model seem sorely lacking in the simple ability to draw pixel or line.
Just because they make an online game doesn't mean all their games are going to be online from now on. FFXII is offline: http://www.ffinsider.net/ff12/
Do game publishers/developers pay to get games reviewed in popular magazines? 'Cuz it looks like I did receive the Unreal II demo on my PC Gamer CD delivered yesterday.
This has come up many times, and my response has always been that this should be possible through the use of VBScript (no modifications to the engine necessary). VBScript has access to COM, and COM components exist (or can be written) to access network APIs. I just haven't had the time to try this myself.
Those who want to program are still going to learn to program. But I think this kind of program just opens up game development to a wider audience -- people who otherwise maybe wouldn't do any development at all. So the intention is not to herd beginning game developers into one way of thinking, but to invite other creative people / artists with ideas to try expressing themselves in this medium by making it generally more accessible.
I see it as a stepping stone for young / beginner game programmers. Many game programmers want to make a platform game, but have trouble visualizing how all the pieces fit together behind the scenes. With this kit, not only can they see what makes up a side-scroller at a high level in the IDE, but since it's open source VB, they can even see and maybe understand the code behind it.
It's also a tool for experienced developers who, maybe, just want to lay out a map and see how their tiles fit together or how parallax scrolling will look, but haven't had time to write their own engine yet. Or maybe the artist wants to see their graphics on a map before the developer is done with an editor or engine.
Oh, and there is one other possibility besides MIDI interference. I have noticed occasionally that DirectX gets confused and starts running DirectX (or at least DirectDraw) very slowly. Then everything works better after a reboot. So you might want to try a reboot if you haven't. (BTW, I use the Detonator drivers too, IIRC.)
Sometimes the MIDI music can slow things down significantly (both the included games use MIDI music). Rolly the purple ball uses WAV music, which I've found runs at a much more steady pace on some systems. So that game might still be worth trying. As a matter of fact, the biggest complaint on Rolly the Purple Ball was that it ran *too* fast. There is, however, a frame rate limiter control if you think your game runs too fast. So that's not really a problem either.
If you had tried it, I don't think you would call it slow. Yes, it was made with VB, but it uses a C++ graphics engine built on DirectX, which allows it to run at pretty high frame rates. I've seen frame rates in excess of 100 FPS for a full screen scrolling map in 640x480 16-bit color.
Slashdot Mirror
You forgot to divide by 100 downloads per song.
Are you trying to make a point with sarcasm? If so, I have to point out, that's neither how real keys nor software keys work. If you're caught, you're in trouble either way.
Why has nobody mentioned the obvious analogy? It's a "key" for crying out loud. Losing it is "like" losing a key. If you lose the key to your house or car, you just get another. OTOH, you do still have to prove that you own it some other way. Can software registration records be used for this purpose?
Like I said, with more effort, the results could probably be improved, but due to the way software is designed, it's not always as easy as it sounds to reach theoretical limits (10,000 records in 1 second) when taking into account other design considerations. Also, 10,000 records cannot be downloaded in 1 second when your remote system is using a modem, which many people still do from remote locations.
Reencoding them as you suggest would be equivalent to converting say an mp3 to ogg format - a surefire way to lose quality with little gain
I don't think that's what was being suggested. I think I know what was being suggested because the same thought occurred to me. Why not just improve the JPG format rather than invent a compression algorithm on top of it? The reason I would expect this to be better is the very same reason you state -- going through two separate conversions/formats is less efficient. Why not improve the JPG format itself rather than use the lossy JPG compression and then introduce a separate (lossless) compression on top of that? I would think that working directly on the JPG format would allow you to get a better quality-size value (more quality and/or smaller size). Introducing a lossless compression on top of JPG is interesting, but integrating something into the JPG algorithm that still allows for loss could probably get better results.
This may all sound funny (I'm guilty of thinking that as I read some of this too) but when I think about it and realize how real it is, it starts to scare me. Cars in particular are one situation where people go on auto-pilot and might react before thinking. We have a lot of stories about people who "almost" did things... I wonder if there have been real accidents that people don't dare share. And I wonder if the dangers increase as games become more realistic (a more realistic emergency brake controller for those who have mentioned using that, for example).
I think it's not entirely about being able to distinguish between reality and game, but also (or mainly) about switching your "autopilot" to react appropriately. Driving may be the most prevalent and severe case to deal with (just a guess). If you've been driving in a game all day, you have trained your autopilot to react in certain wayt to certain road circumstances. Obviously when you then go out on the road you consciously realize that you are in reality now, but I think your autopilot (which is used heavily during driving) doesn't care -- it just has a certain set of circumstances and reactions that it's been trained with. So if you're not consciously thinking about what you're doing, you may easily be inclined to react inappropriately to certain circumstances.
I played Tetris on the computers in the CS lab in college just a little too long/often and later found myself trying to figure out how writing on the blackboards during class could fit together.
I program for an international ERP software company, and one thing I notice in addressing such challenges is that the desire to centralize the data and yet provide remote access is the counterbalance to high performance. In MS Access, a long scrolling list of items would not be such a problem when you're working with a local database. But since the data needs to be centralized, and access to the system needs to be remote, ERP systems have to be designed in a way that can allow remote users to deal with a managably small amount of data at a time. Often times the lists you deal with in an ERP system are so large that it's not practical (for the user) to view the entire list anyway (even if performance is optimal), so a user will often times type in a part of a name to narrow down the list to the items they are interested in. But depending on where you strike a balance, performance results may vary greatly for long lists.
Not to defend Axapta (I haven't used it myself); it's just a relevant observation I have about designing ERP software. With enough time and effort, I would think one could do better in getting the best of both worlds (performance and remote access), but it does have to be intentional.
Well there appears to be some value in the idea because, at least for a while, thinkgeek.com was selling them. They're just not as cheap as you might want, but they are certainly cheaper than $6000.
I made a program that can actually use RSA for encrypting a whole file/message (based on base 256, base 64 and base 10 conversions of RSA transformations on huge numbers). Is is kinda slow with larger key sizes, but not intolerable. And it allows quite large keys (larger than 1024 bit).
I think the biggest challenge facing humanity right now is energy. I don't know if everyone realizes how many of the world's problems are based on energy consumption and how much better off we would be with some alternative energy source that is safe, clean, cheap and plentiful. Surely we've put our minds to it before, and maybe it's futile to hope for such a miracle, but maybe it's time to try again. Any hope of finally getting that cold fusion to work? :) Or maybe some combination of high yield solar panels with efficient storage cells.
Imagine -- forget mideast oil and all their conflicts; forget pollution -- most of it comes from our current, primary energy sources; forget nuclear waste disposal (after we're done with what we've already got to deal with); and if the energy source is reasonably self-contained / localized (like solar panels on the house), forget transmission problems and dangers. If I had to pay double taxes for 2 years to get this worked out, I'd be all for it!
What about the budding game programmer's favorite? JavaScript and the general browser object model seem sorely lacking in the simple ability to draw pixel or line.
Nobody seems to have problems with putting the CD into a game console to play it.
Just because they make an online game doesn't mean all their games are going to be online from now on. FFXII is offline: http://www.ffinsider.net/ff12/
The Scrolling Game Development Kit recently released a new version and had a story on Slashdot.
XML: /></Leg> /> />
/>
<foot-shot>
<Leg side="left"><foot
<Gun id="1" type="colt"
<Bullet GunId="1"
</foot-shot>
"Whaddya mean I can't shoot without XSL? Aw fine..."
XSL:
<xsl:for-each select="/foot-shot/leg/foot">
<xsl:shoot with="/foot-shot/Bullet[GunId='1']" target="."
</xsl:for-each>
"Whaddya MEAN xsl:shoot is a Microsoft-specific non W3C XSL extenstion!?"
Do game publishers/developers pay to get games reviewed in popular magazines? 'Cuz it looks like I did receive the Unreal II demo on my PC Gamer CD delivered yesterday.
This has come up many times, and my response has always been that this should be possible through the use of VBScript (no modifications to the engine necessary). VBScript has access to COM, and COM components exist (or can be written) to access network APIs. I just haven't had the time to try this myself.
Those who want to program are still going to learn to program. But I think this kind of program just opens up game development to a wider audience -- people who otherwise maybe wouldn't do any development at all. So the intention is not to herd beginning game developers into one way of thinking, but to invite other creative people / artists with ideas to try expressing themselves in this medium by making it generally more accessible.
I see it as a stepping stone for young / beginner game programmers. Many game programmers want to make a platform game, but have trouble visualizing how all the pieces fit together behind the scenes. With this kit, not only can they see what makes up a side-scroller at a high level in the IDE, but since it's open source VB, they can even see and maybe understand the code behind it.
It's also a tool for experienced developers who, maybe, just want to lay out a map and see how their tiles fit together or how parallax scrolling will look, but haven't had time to write their own engine yet. Or maybe the artist wants to see their graphics on a map before the developer is done with an editor or engine.
Oh, and there is one other possibility besides MIDI interference. I have noticed occasionally that DirectX gets confused and starts running DirectX (or at least DirectDraw) very slowly. Then everything works better after a reboot. So you might want to try a reboot if you haven't. (BTW, I use the Detonator drivers too, IIRC.)
Sometimes the MIDI music can slow things down significantly (both the included games use MIDI music). Rolly the purple ball uses WAV music, which I've found runs at a much more steady pace on some systems. So that game might still be worth trying. As a matter of fact, the biggest complaint on Rolly the Purple Ball was that it ran *too* fast. There is, however, a frame rate limiter control if you think your game runs too fast. So that's not really a problem either.
If you had tried it, I don't think you would call it slow. Yes, it was made with VB, but it uses a C++ graphics engine built on DirectX, which allows it to run at pretty high frame rates. I've seen frame rates in excess of 100 FPS for a full screen scrolling map in 640x480 16-bit color.