 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is a spin of pf the "Please tell me it isn't so!" thread and so off
topic to off topic.
Clipka:
>>> > > it's a bit complicated... (Because it *is* a bit complicated.)
David:
>> > If it is (and I can't believe that it's all that complicated), why is it??
Well, exasperated, I'm willing to admit it: Graphics programming in
Windows is
complicated, too complicated to bother with it appears to me. So I guess
I'll have
to admit that Windows programming in a multitasking environment is
*hard* and not
much fun and I can't do it , at least with tools and help I have been
able to find.
Thanks for all the help. If anyone knows anything that might help me dig
into it, let me know.
"I'm not smarter than a fifth grader." ;)
(My thought about Microsoft and all its current software are *very*
uncharitable.)
David :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> Thanks for all the help. If anyone knows anything that might help me dig
> into it, let me know.
Use a higher-level library. Use Tcl/Tk, or Qt, or .NET, or any of the
hundreds of free systems that let you say "create a window X by Y, put an
image there, and give me commands to set colors into pixels." It's about 10
lines of Tcl code, for example, and probably not a *whole* lot more .NET code.
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 30/07/2009 21:41, David H. Burns nous fit lire :
> This is a spin of pf the "Please tell me it isn't so!" thread and so off
> topic to off topic.
>
> Clipka:
>>>> > > it's a bit complicated... (Because it *is* a bit complicated.)
>
> David:
>>> > If it is (and I can't believe that it's all that complicated), why
>>> is it??
>
> Well, exasperated, I'm willing to admit it: Graphics programming in
> Windows is
> complicated, too complicated to bother with it appears to me. So I guess
> I'll have
> to admit that Windows programming in a multitasking environment is
> *hard* and not
> much fun and I can't do it , at least with tools and help I have been
> able to find.
>
> Thanks for all the help. If anyone knows anything that might help me dig
> into it, let me know.
>
> "I'm not smarter than a fifth grader." ;)
>
> (My thought about Microsoft and all its current software are *very*
> uncharitable.)
>
> David :)
Just 0.002€ (yes, only 10% of usual): have a look at fox-toolkit library.
(C++)
Compatible with X11 & Windows, high level enough and yet allowing finer control if
needed.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> (My thought about Microsoft and all its current software are *very*
> uncharitable.)
For example, attached is an old Tcl program that draws fractals on the
screen then saves them as image files. It should still run. (Drawing pixel
by pixel in Tcl is very slow, by the way. You're supposed to use
higher-level objects.)
Also attached is an old OLD Java program[1] which calculates a rather
complex image (sample attached) based on Conway's game of life, but in so
doing draws it on the screen. The things to note is that the main class
inherits from Frame, the update() function (near like 550) and the paint
function (near line 500). The rest is just figuring out what needs to be
painted. I don't know if this one will still run as-is, but it's basically
the same idea used in most lower-level toolkits. You create a window, and
when you get the request to paint the window, you get a "graphics" to paint
on which has a bunch of methods you can use to change what's displayed.
You can look at
http://www.java2s.com/Code/CSharp/2D-Graphics/Setimageresolutionandpaintit.htm
for drawing with .NET. The thing to note is again the class inherits from
"Form", Main() calls Application.Run with a new instance of that form, and
the form overrides the Paint event to also invoke Form1_Paint. Inside the
Form1_Paint routine, you get out the Graphics object and invoke methods on
it for filing rectangles, darwing images, lines, etc whatever else you want.
It's in the docs. Follow the breadcrumbs backwards for examples of how to do
all kinds of stuff.
What more do you need?
[1] Hence the ".JAVa" extension. ;-)
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
Attachments:
Download 'fractal.tcl.txt' (4 KB)
Download 'cavern.java.txt' (18 KB)
Download 'cave7.gif' (82 KB)
Preview of image 'cave7.gif'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> What more do you need?
To be perfectly frank, a lot --or maybe nothing. :)
I must retreat and study these.
Thanks :)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le_Forgeron wrote:
> Just 0.002€ (yes, only 10% of usual): have a look at fox-toolkit library.
> (C++)
> Compatible with X11 & Windows, high level enough and yet allowing finer control if
needed.
Thanks :)
David
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David H. Burns wrote:
> "I'm not smarter than a fifth grader." ;)
http://www.gamearchitect.net/Articles/SoftwareIsHard.html?dupe
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] san rrcom> wrote:
> http://www.gamearchitect.net/Articles/SoftwareIsHard.html?dupe
It actually *is* possible to have software development which produces
(almost) bug-free programs on schedule and within budget. However, getting
to that point is extremely hard and probably prohibitively expensive.
I loved that one article (which has also been referenced here in the past)
on how software is produced by NASA. The development system is absolutely
draconian and bureaucratic, where not a single feature or even line of code
is added, removed or modified without the change being carefully documented
and passed through an admission process. The rules are mind-numbingly strict
and bureaucratic.
However, it works. Where projects of similar size in other, more regular
software companies, have something like 5000 bugs found in beta-testing
stage, NASA software projects have something like 5. And not just critical
bugs. *Any* bugs.
And they *learn* from the bugs. Every time a bug is found in beta-testing,
they carefully study and document the *reason* why the bug got through to
beta-testing in the first place, through all the safeguards and development
methods, and once the reason is understood, these safeguards and methods are
improved so that similar bugs will never pass again undetected.
(This idea of actually learning from bugs and documenting them in order
to avoid them in the future is actually a superb idea. However, how many
companies do that? I'd say the amount is really, really small. Most developers
just fix the bug and *forget* about it. Then they are doomed to repeat the
same process again in the future in similar situations.)
And as said, they not only produce virtually bug-free programs, they do
so in schedule and within budget. How many other companies can say that?
I liked how the article talked about the one guy who was a developer at
NASA, who wanted to go to the software industry where he could develop
software with more freedom, without all the bureaucracy. He got shocked
at how bad software development was elsewhere, and returned to NASA after
a few years.
Of course getting to this kind of development must be rather hard and
expensive (at least at first). It also requires a kind of mentality and
expertise that most project leaders just don't have.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Of course getting to this kind of development must be rather hard and
> expensive (at least at first). It also requires a kind of mentality and
> expertise that most project leaders just don't have.
I think it's probably similar for a lot of safety-critical code.
The thing about NASA is they have safety-critical code, extremely bad press
when it fails, and a software budget dwarfed by everything else they do.
When the concern doesn't include how much it costs or how long it takes,
it's a whole bunch easier to make perfect code.
Having the same development platform for 35 years can also help, as does
having every bit of specs about how absolutely everything works. And in all
honesty, the programs aren't all that big. How many bugs have you written
because you're using some infrastructure code that isn't documented
correctly and completely?
Which is not to say they're not awesome. I'm just saying they're solving a
different problem than 3DRealms was trying to solve. :-)
http://www.atarimagazines.com/compute/issue132/92_Space_shuttle_techno.php
http://www.popsci.com/node/31716
--
Darren New, San Diego CA, USA (PST)
"We'd like you to back-port all the changes in 2.0
back to version 1.0."
"We've done that already. We call it 2.0."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New <dne### [at] sanrrcom> wrote:
> http://www.popsci.com/node/31716
Btw, it really amuses me when the Moon landing conspiracy theorists make
the point that the lunar lander computers had less computing capacity than
a modern cellphone, like that was some kind of proof that the landings were
impossible.
These people have clearly not seen any 4k intros (it's really amazing how
much functionality you can squeeze into 4 kilobytes of code), or tried to
find out how much hardware a cellphone really has.
(Personally I see it the other way around: I'm amazed at how much
computing power there is in a device which you can hold in your hand.
Technology has really taken huge leaps.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
