Graphics mode

[Rick DeNatale]

Eeek! =A0I feel old. =A0I did AP CompSci back 21 years ago. =A0It was in = Pascal
then......

Don't feel so old, I got my BS in CompSci 35 years ago, Fortran, PL/I,
Lisp, Snobol..., punch cards, paper tapes, teletypes.

I don't know if Pascal even existed then.


--=20
Rick DeNatale

Blog: http://talklikeaduck.denhaven2.com/
Twitter: http://twitter.com/RickDeNatale
WWR: http://www.workingwithrails.com/person/9021-rick-denatale
LinkedIn: http://www.linkedin.com/in/rickdenatale

 

[Colin Bartlett]

...
Don't feel so old, I got my BS in CompSci 35 years ago, Fortran, PL/I,
Lisp, Snobol..., punch cards, paper tapes, teletypes.

I don't know if Pascal even existed then.

Apparently it did: "designed in 1968/9 and published in 1970 by Niklaus Wirth":
http://en.wikipedia.org/wiki/Pascal_(programming_language)
(And I was (still) using it for my home use in 2007.)

Which gives me an opportunity to say something I've been meaning to
say for one or two years, that I very much enjoyed your "About me"
http://talklikeaduck.denhaven2.com/2006/07/29/about-me
One thing that interests me is why people - for reasonable reasons -
decide to use one thing rather than another and later use something
else, so I'm interested when you say:
"But for me right now, while I wouldn't be unhappy if I had to go back
to Smalltalk, but I feel happier with Ruby."
http://talklikeaduck.denhaven2.com/...d-to-stop-using-ruby-and-go-back-to-smalltalk
(And I'm interested in the views of people who are "happier" with
Smalltalk, Python, etc.)

On a potentially dangerous topic, not least because of:
http://www.phespirit.info/montypython/four_yorkshiremen.htm
(especially because this is a Ruby list!)
as part of my BA Maths degree: a one term course in computer
programming in 1970 in Algol 60 (or maybe 68) using punched cards. And
in 1974: actuarial exams using slide rules and log tables; calculating
premium tables using using Facit hand calculators and electric (*not*
electronic) calculators! (We started using the first - mains electric
powered - electronic calculators not long afterwards.)
http://en.wikipedia.org/wiki/Facit
http://en.wikipedia.org/wiki/File:Calculator_facit_hg.jpg

One thing I liked about Algol (in retrospect - I didn't know enough to
appreciate it in 1970) was that instead of:
if v < 0 then x = -v else x = v
you could do something like:
x := if v < 0 then -v else v
and something I liked very much about Ruby when I found out about it
in 2002 or 2003 was you could do that in Ruby.
Some full example Algol code:
http://www.engin.umd.umich.edu/CIS/course.des/cis400/algol/average.html

*Really off-topic*
http://en.wikipedia.org/wiki/Calculator
http://en.wikipedia.org/wiki/Marchant_Calculator
One thing (just before my time) people used to do with electric
calculators like the Marchant was to set the digits spinning and then
switch it off with the aim that when the digits finally stopped
spinning it would be all "9"s! Of course, one could simulate that
game, but would the simulation be the same? (Maybe at least less
resource intensive: those old calculators were heavy.)

 

[Michal Suchanek]

Well, this is the way I do it in C++:

#include <graphics.h>
void main(){
=C2=A0 //initializing graphics mode
=C2=A0 =C2=A0 =C2=A0 =C2=A0 int gdriver=3DDETECT, gmode, errorcode;
=C2=A0 initgraph(&gdriver, &gmode, "C:\\Progra~1\\BORLANDC\\BGI"); error= code
=C2=A0 =3D graphresult();
=C2=A0 if(errorcode!=3DgrOk) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0cout<<"Graphics error!!!\n"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<"Press any key...";
=C2=A0 =C2=A0 =C2=A0 =C2=A0getch();
=C2=A0 =C2=A0 =C2=A0 =C2=A0exit(1);
=C2=A0 }
//...
//AND HERE IS DA MAIN PROGRAM CODE.
//...
}

I'd like to make my ruby prog like this. Any Ideas? P.S.: If you have an
idea, please describe it in a way you would talk to a noob, for I'm
really green. Plus, I use Ubuntu, no comment.

Thanks!

Wow! That's a blast from the past! I'm guessing it's either Borland C++
for DOS (where screens actually did have "graphics mode" versus "text
mode"[1]) or their library for Windows which simulated the old DOS
library by opening up a window and drawing in that window. (I programmed
for this emulation library 10 years ago as part of an AP computer science
assignment.)

I'm guessing that you're moving from your knowledge of old DOS/Windows
and C++, you're moving to Linux and now you want to learn a nice shiny
new language for programming in Linux, so you chose Ruby.

If you're planning on writing GUI applications, you should either look at
Ruby/GTK+ or QTRuby, both of which are good frameworks providing all of
the standard widgets that you find in word processors, web browsers, and
the like.
http://ruby-gnome2.sourceforge.jp/
http://techbase.kde.org/Development/Languages/Ruby

If you want full screen graphics (or full-screen graphics in a window),
which is often useful for game programming, you should look at Ruby/SDL.

http://www.kmc.gr.jp/~ohai/rubysdl.en.html

Ultimately you should take the time to learn a little of both.


[1] FWIW, Linux has this too, but you only think about it that way if
you're writing an X server or programming in svgalib. For the most part
that view of the world is obsolete by about 20 years.

Well, actually this is not that obsolete. If you open an X window you
can use it exactly the same way (as long as the kind user does not
resize it for you). There is the Linux framebuffer console which works
pretty much the same (which is being obsoleted for some/most
chipsets). Yet as it is being thrown out through the door it climbs
back through the window in the form of KMS.

Writing X servers is not that uncommon, too. Linux/BSD ports on some
obscure platforms are in need of X server implementation/improvement
(ie. Nintendo DS - anyone would finish it?)

And since we will have KMS it should be much easier to throw away
Xfree86 and finally get some decent GUI system which is not patch on
patch of decades old cruft.

GRUB is currently in the process of implementing a graphics menu
system for eye candy, non-Latin language support, and non-VGA platform
support which (surprise!) has to deal with this 20 years old direct
memory access approach.

In fact, there is a windowing system (EWS) that is completely based
around emulated video memory bufffers and has no pre-made buttons,
canvases, pixmaps or anything like that. It's dead simple, fast
enough, end even has decent security.

Thanks

Michal