 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
And you've been tricked! There may be 99 gems of actual wisdom on that page, but you've fallen for decoy with that one.
If two programmers will code essentially the same solution, the programmers are NOT coding. Rather the programmers are, in fact, acting as the compiler. This is a waste of human time. I think the point is more that observing that this is a problem does not bring us any closer to a solution. Languages like Haskell are finally getting more widely used these days so maybe there's hope for the world (although I found Haskell pretty hard for just getting things done when I used it, that was 15 years ago now though...).
The problem is this: A compiler is a transformation program that transforms one model to another. In the case of a C compiler, the input model is source code that conforms to the C spec, and the output is machine code that conforms to the spec of the targeted platform.
The input model is already an abstraction in that it abstracts (somewhat) from the details of the target platform. As you know, abstraction means omission of details, that is, every abstraction entails a (purposeful) loss of information. In the case of C, the missing information (platform details) can be added by the compiler because the information can be derived from the C spec and the platform spec. What you want is even more abstraction, which again entails more loss of information. The question is, how can we get this information back during compilation? If you want an automated compiler from your more abstract input model, you need to store the missing information somewhere and add it back in during compilation. This is how toolkits work. For example, in a game toolkit like the latest Unreal Engine, you work on a much more abstract level, and the missing information (that is, how to render things, how to handle input, how to handle sound etc.) is added in when the game is assembled by the compiler. Basically, the missing information is again stored in a platform specification. In this example, the platform specification is the specification of the engine, its toolchains, its file formats, and so on. Of course all of this abstraction comes at a price, and that is less flexibility. You are restricted in what you can do with the engine and how you can do it so that the "compiler" can add in the missing information. But what you seem to want is having the ultimate flexibility AND a large degree of abstraction. You want to specify a very abstract solution and have the compiler figure out how to generate machine code from that. Again, the compiler needs to add the missing information, but where does it come from? If you formalize it somehow as a model, you must again limit the user / programmer in what she can do with your system. And therein lies the problem: The more abstract your language, the more restricted it must be. Don't want do deal with memory representation? Use Java, but suffer the restrictions in performance and memory consumption. Don't want to specify types and such? Use Python/Ruby/whatever, but suffer the restrictions in performance and safety. The challenge of abstraction is to balance it with flexibility, and apparently this is such a hard problem that the entire software engineering discipline has not been able to solve it (generally) and is nowhere near a solution, too. Some abstractions (languages) are "good" in this sense and others are not, but we don't precisely know why. But! you say - can't the computer guess the missing information somehow? My brain can do it, so the computer should be able to, too! No, it cannot, because it's not creative and needs precise mathematical descriptions. Only our brain can do this. But! what about Prolog and such? You don't even need to specify a solution, only a problem! Yes, but specifying complex problems so that a system like Prolog can derive a solution is (in general) much harder than inventing a solution in your head and coding that up, even if that's hard too. Logical programming is very useful for a specific set of problems, but it is more targeted at the scientific and engineering communities and are usually applied in AI and computer linguistics. You can't write a 3D game in Prolog (AFAIK), nor would you want to. So, I for one don't believe that there will ever be a system that will write your code for you. Or if computers ever get "smart" in this way, I doubt we will be around to use them. Maybe our grandchildren will. Imho C is a necessary and best kludge to get the most of out hardware and hence is the underpinning of serious programming. C++ is an even uglier but still great kludge for the reasons sleepwalkr says.
But I for one *love* my main language. Wish/Tcl is a beautiful archaic thing with aspects of functional programming,and great interfaces to a huge (slightly ugly) graphical toolkit, and to C/C++ as well. wish <<! pack [button ! MD3 support for Fitzquake and Quakespasm!? :)
I for one can use this already... I'm using it to replace models for KMquake2 and currently working on a new Shambler model for the Original Quake. But ofcourse it ends up as an MDL in Quakespasm and Fitzquake... My pipeline goes from 3dsmax exported to FBX and then I simply use Neosis for the conversion to MDL right now. Works perfectly but the model formats lack of precision makes me sad. If somebody adds MD3 support I could pretty much instantly take advantage of it. I would still use the quake palette though because I prefer the pixel retro look. IF you add it I will use it! Regardless https://www.dropbox.com/s/ckylp58vipdh9e3/Shambler_Wip.jpg?dl=0 Here is a sneak preview for those wondering what it looks like. i've seen vertex dancing on md3 though... it's a lot less, but it's still there. is there no better format?
what about something similar to external textures...
so you have your player.mdl and then you have player_0.fbx, player_1.fbx, etc... and give external model information. the workflow these days is to export multiple single frames and use tools to merge them into a mwh:I think the point is more that observing that this is a problem does not bring us any closer to a solution.
I just want to prevent myself from writing bad code in the future (and I hope I have the definition correct and complete). And needed to know what "bad code" looks like --- bad code isn't obvious. That is all I can do. sleepwalkr:So, I for one don't believe that there will ever be a system that will write your code for you. Is anyone actually writing any complex code to begin with? I don't know that 1) Anyone is. 2) If it is even possible to do so. You've put tons of work into Trenchbroom, but isn't it all rendering triangles by distance at the end of a frame, when everything is said and done? Developers: creators of simple works, using crude tools. Rewarded with praise for winning the endurance and stamina test using crude tools that are hard to understand, use correctly and master. The idea conceived in seconds, the debugging achieved in hours, but the implementation --- should it ever come --- will take months, if ever at all. However, if you master a low-level language like C, you can do almost anything without any natural limitations except time. Knowing time is the limitation, I want to re-evaluate my use of it. I do know the definition of insanity is doing the same thing over and over and expecting a different result. I think this sums up current thoughts on the subject quite well: http://forums.inside3d.com/viewtopic.php?f=1&t=1283&start=2 I debated on clicking 'Submit'. Logic says no. The Labatt's Blue says "apathy now". And who am I to question the logic of beer! Just a quick reply then:
You've put tons of work into Trenchbroom, but isn't it all rendering triangles by distance at the end of a frame, when everything is said and done? Not by a long shot. Currently we can choose between linear filtering and nearest-neighbor filtering. How about giving hqx a try?
The filtering that is currently available is there because the hardware supports it, hqx would probably have to be done by up sampling the textures in software and loading the higher res images to the video card. Which you could also do manually using external textures.
Yeah hqx only looks half-decent on stuff like nes sprites - In Quake it would just look like you've upscaled the texture then run them through some ugly watercolour filter or something.
I looked into other texture filtering once and it is not worth it unless you are into amateur painter art.
No idea what I used to create them but here is scale4x: https://transfer.sh/Liu3e/scale4x.7z
new super8 release: http://super8.qbism.com/2015/02/build-2-bsp2-map-support-and-transparency/
bsp2 and 2bsp thanks to quakespasm source for guidance http://super8.qbism.com/wp-content/uploads/2015/01/qbs8_017.gif also, that RRP video revealed to me a design flaw in the burning player effect from rubicon 2 -- if your health is > 100, you can't pick up a health pack, which means you can't stop the burning!
It really is fun to play Quake on, and it's often overlooked (I have to remind myself it exists occasionally). What I really love is low-grav + gore. This makes Quake even gorier :)
Here's some gore screens from my low grav map (coming soon I hope) - https://www.dropbox.com/s/vfu25hshcyv71s2/qbs8_003.png?dl=0 https://www.dropbox.com/s/p6ar35jwz14y9p1/qbs8_004.png?dl=0 https://www.dropbox.com/s/9cdnkifemxz2tld/qbs8_005.png?dl=0 https://www.dropbox.com/s/pyedcf3wwqqa453/qbs8_006.png?dl=0 super8 - pretty cool, but when fog and coloured lighting is all going on, you tend to lose a lot when you try and map that back to the quake palette.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |