It is currently Wed Jul 18, 2018 1:36 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 177 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 12  Next
Author Message
PostPosted: Sun Dec 03, 2017 9:07 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Yes,but it's not 100% software,i think mode 7 must be used for zooming .


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 9:43 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3347
Location: Nacogdoches, Texas
Zooming?

I think that's the first time I've seen that 3D segment from Toy Story on the SNES. What's really impressive is how smooth it runs; looks like it even runs at a higher framerate than the Genesis version. Of course, the resolution is lower, so there's that.

The people in the comment section are crazy; the Genesis version looks better but the SNES version sounds better? Wtf? I like the dark colors of the Genesis version, but I don't think that makes it more technically impressive. The SNES version sounds like hot garbage; the only part that sounds clearer is the "hello" voice sample, but it sounds nothing like the aliens from the movie. Sounds like people are giving pre-programmed responses based on "knowledge" of the hardware. :lol:


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 10:38 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2713
The SNES version has more colors onscreen. I don't think it's zooming in, because it looks as sharp as the Sega version, just with a smaller screen.

I like the "preprogrammed responses" comment. It's like how Thunder Force 3 runs at the same speed on both SNES and Sega Genesis and people think the Genesis version is twice as fast. I've seen slowdown on both versions of the game, and they're pretty much in the same places.


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 11:45 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
because it looks as sharp as the Sega version, just with a smaller screen.

Yes i have also noted that it's not as pixelated as usual with mode 7.
It's really good if all the redering is done with the CPU, and mode 7 is only here to have a "chunky" display .

thunder spirit on snes is really bad coded, it slowdown for nothing,in the space level, there is a lot a things on screen and it doesn't slowdown that mush compared with the first levels .

https://youtu.be/yiFV_-ENxjc?t=9m18s


Last edited by TOUKO on Sun Dec 03, 2017 12:38 pm, edited 2 times in total.

Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 12:29 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2713
The weird thing is that the frame rate only drops a little bit, like it's running at 45 fps.


Top
 Profile  
 
PostPosted: Wed Dec 06, 2017 5:31 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2713
Besides the whole CPU speed comparison stuff, I see the same type of "logic" in everything including college academia. College Professors either just believe what other people with PHDs told them, or make shit up without any kind of experimentation or anything. I really don't give a damn what kind of nonsense is on "US department of education" website. Everything is just circular reporting.


Top
 Profile  
 
PostPosted: Fri Dec 08, 2017 1:22 pm 
Offline
User avatar

Joined: Sun Jun 05, 2005 2:04 pm
Posts: 2149
Location: Minneapolis, Minnesota, United States
I don't think actual logic is the issue. It sounds to me like what people call logic isn't really logic, which is an issue.


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 6:49 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2713
Here is some more "logic".

Attachment:
don knuth's circle of logic.png
don knuth's circle of logic.png [ 22.26 KiB | Viewed 786 times ]


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 7:10 pm 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 393
Location: FL
You're kind of wildly misrepresenting what Knuth actually said:

Quote:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.


In other words, optimize when it actually matters, and be able to recognize when it doesn't.


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 9:27 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2713
It would've made more sense if he said "unnecessary optimization" instead of "premature optimization". "Premature" sounds like you shouldn't make any optimizations early on.


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 9:53 pm 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 253
Location: Seattle
But Knuth is speaking out against a particular form of unnecessary optimization. The idea is that it's hard to predict in advance what parts of your code will be the bottleneck (and sometimes even once you've written your code it's hard to know where the bottleneck is without profiling), so don't expend lots of effort micro-optimizing stuff and making it harder to maintain before (i.e. prematurely) you have an idea if that's worth doing.

At risk of appealing to authority here, you're almost certainly not smarter or more experienced (or better at choosing words, for that matter) than Donald Knuth. That doesn't mean smart people can't make mistakes or anything, but you probably ought to apply the principle of charity and try to listen to and understand what smart people are saying before attributing the most banal and trivially incorrect possible reading to it so as to dismiss it out of hand.


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 10:54 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2713
That's another thing that bothers me. I hate coming across as a know-it-all if experts in a field want me to believe something that doesn't add up, or sounds politically biased. If I find just one flaw in somebody's logic, people might think I'm a jerk who thinks he's smarter than everyone else, and I just want things to make sense.


Top
 Profile  
 
PostPosted: Mon Dec 18, 2017 11:48 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6405
Location: Canada
psycopathicteen wrote:
It would've made more sense if he said "unnecessary optimization" instead of "premature optimization". "Premature" sounds like you shouldn't make any optimizations early on.

No, thats not his point at all. Everything he talks about in the context that quote applies only to early optimization, and the accumulated effect they then have over the course of the project.

"Avoid unnecessary optimization" would be an unhelpful platitude. Knuth's advice is offering his intuition based on his experience: that mistakes made due to optimizing early are overall more harmful than the mistakes made by not optimizing early enough. It's advice to try to recognize when you're making an early decision like this, consider its long term implications, and if unsure he would probably want to err on the side of optimizing too late.

The reason people optimize early is to avoid optimizing too late: the case where you have to rewrite/refactor a bunch of stuff because the structure of things made it impossible to fix locally. That case is something real to worry about, but Knuth was warning against the long term impact of doing it too early, which in his experience was often overlooked. Over the long term code has to be revised many times, and requirements frequently change, and optimization has a tendency to make code both more difficult to maintain and more specialized in its requirements. On the other hand, most late optimization opportunities are easy local fixes, so the rewrite case is rarer, and even then the time spent in a rewrite might be comparable to the time spent in added maintenance if it had been done earlier. That's the perspective he's trying to share, and it would not at all be intimated by warning merely about "unnecessary" optimization.

It's not at all a statement that you should never optimize early. It is an opinion about which category of mistake is most important to avoid, advice from a seasoned professional about how to weigh hard decisions in code design, not some sort of dogmatic rule.

...and just in case it's not clear, it is talking about a specific kind of optimization: something that makes code faster but more complex. Not all optimization falls into this category, but almost all optimization that a programmer needs to make difficult/critical decisions about does.


If you'd like to see its actual context, one of the cited versions of the idea from that wikiquote link is this 1974 paper, about GOTO but also touching on a bunch of general programming issues:
http://web.archive.org/web/201307312025 ... -knuth.pdf


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 2:19 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7443
Location: Chexbres, VD, Switzerland
Man, this Knuth quote has been regularly geting on my nerve and I already wrote my tought about it on 6502.org forums, so I'm not going to do this again, but I'll just quote myself.

On 6502.com, Bregalad wrote:
I absolutely hate those one lined so-called "rules". They make absolutely no sense, as if you could summary good and bad programming practice in 5 (or so) lines.

It depends so much on the context, if you are in education, or industry, if you are writing for your hobby or just because you're paid to do so, if you have deadlines or not, if you want to make elegant code, and of course even if in theory the programming language is not related to programming in itself, in practice it is, so yes it will depend on the programming language.

It is absolutely wrong to say you can't know where a program is going to spend it's time. In fact if you have half a brain you can guess it very easily. The only exception is if you are doing system calls and have no idea what the library will do behind it. Which may be pretty much always the case of people programming in very high level language, where they have no idea what they're actually doing on the machine.

And, the sentence, "premature optimisation is the root of all evil" is simply stupid and was probably a dumb joke, but people took it seriously.

I think it would be trivial to find one evil which is not due to premature optimisation. For instance, nazism was not a premature optimisation. Enough said.

Now let's pretend "premature optimisation is the root of all bad-programming practice (aka "evil") ". Again this is wrong. Some of the random programming practices that comes in mind :

- Bad indentation
- Variable names that makes no sense or aren't related to the variable's purpose
- Function names that makes no sense or [...]
- Not comment what a function expect as input and output
- Writing too much stuff on one line like : while (--i != function_call(arg1++, arg2))
- Copy-paste a function and make it only slightly different, instead of using an extra argument

None of those bad practices are premature optimisation, so again this sentence is plain wrong.

Now let's dumb it down to "premature programming optimisation is the root of some bad-programming practice (aka "evil")"

Then finally this is true of course (at last). If you want to make a super optimal program before writing it, there is higher probability you'll write spaghetti code and fail or simply loose interest in continuing it, because it's too much effort (if you're a hobbyist).

However, completely ignore any kind of "optimisation" when programming is not a very good practice either. You should really think about the proper data structures, so that you'll gain time, and not having to say "oh if I use structure Y instead of structure X, my program could be 10x faster" and having to rewrite everything.

So my advice is to optimize data structure first, then write clear, commented code (having it "optimized" is ok as long as it doesn't discard the comprehension), and finally, make a few optimizations that could alter the comprehension of the code if it is needed.

Also, optimising non-bottlenecks is not a crime. It's just a waste of your time in the worst case, but it won't hurt the performance in any way. Don't get me wrong - optimising bottlenecks is better, but that doesn't make optimise the rest wrong. There is plenty of situations where measuring the bottleneck directly is simply impossible or terribly difficult, so you'll have to resort to cheap heuristics.

Conclusion : I think paradoxally those dumb one-liners and people citing them as if it was the bible is the reason there's so many bad programmers around. In reality most of the approach depends on the context (embedded or not, hobby or work) and programming language. Just don't trust one-liners without thinking.

I'd say : "Dumb one-liners are the root of all evil".


Quote:
The idea is that it's hard to predict in advance what parts of your code will be the bottleneck

Wrong, in most cases it's actually very easy.


Top
 Profile  
 
PostPosted: Tue Dec 19, 2017 11:30 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6405
Location: Canada
Bregalad wrote:
I absolutely hate those one lined so-called "rules". They make absolutely no sense, as if you could summary good and bad programming practice in 5 (or so) lines.

It wasn't a "one line rule" when he said it. I linked the original article it appeared in above.

It is not at all intended as a "rule" against ever optimizing early. It's only the idea that the mistakes of the worst magnitude come from doing so. It's a thing to remember when you're making a difficult decision about optimization, not when the decision to optimize is easy.

In fact, directly preceding the quote in that article, he talks about some cases where you should routinely try to optimize immediately. In context he's not saying anything of the sort you are attributing to it. It's a small part of a much larger, and very practical discussion about optimization (and the point of the article: the place of GOTO in optimization circa 1974).

Maybe the quote is commonly being misused, misapplied, or misinterpreted, I don't know (psychopathicteen's diagram is absurd)... but the point of a quote is supposed to stand in for the larger idea, not encapsulate it entirely. (This is precisely why twitter is so good at fostering arguments; everything is reduced to a "quote" size that can't possibly mean all that it needs to.)


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 177 posts ]  Go to page Previous  1 ... 3, 4, 5, 6, 7, 8, 9 ... 12  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group