Author Topic: System programming vs graphic programming  (Read 11641 times)

bf2

  • Guest
System programming vs graphic programming
« on: July 07, 2012, 05:46:43 PM »
It's perhaps down to the fact that my career started with the IBM mainframe, and I still love the IBM mainframe -- that I absolutely detest graphics programming.

I totally love system programming - low-level architecture, registers, CPU, memory, threads, proccesses, security, OS - these things really turn me on and I love learning about them. But I also feel quite guilty that I keep postponing learning about Windows graphics programmming. I feel that I *should* learn it - and I feel bad that I hate it.

Does anybody else have this problem? Should I see a shrink? :-)

Vortex

  • Member
  • *****
  • Posts: 2059
Re: System programming vs graphic programming
« Reply #1 on: July 07, 2012, 05:55:09 PM »
In my modest opinion, you should have a basic knowledge about Windows graphics programmming to learn about Windows GUI system. You can continue with console applications, than can be fine but fundemental knowledge covering different areas of programming will enlarge your vision.

sinsi

  • Member
  • *****
  • Posts: 1201
Re: System programming vs graphic programming
« Reply #2 on: July 07, 2012, 06:32:06 PM »
Depends on what you define graphics as. Writing a GUI just means reacting to messages rather than a more linear type console program.
You still do the low-level stuff, can't really get away from it nowadays.

Graphics meaning directx/opengl is another matter...
I can walk on water but stagger on beer bourbon.

jj2007

  • Member
  • *****
  • Posts: 9920
  • Assembler is fun ;-)
    • MasmBasic
Re: System programming vs graphic programming
« Reply #3 on: July 07, 2012, 06:32:57 PM »
Should I see a shrink? :-)

Ask DednDave, he has recently made huge progress on Windows GUI programming ;)

bf2

  • Guest
Re: System programming vs graphic programming
« Reply #4 on: July 07, 2012, 07:02:19 PM »
Depends on what you define graphics as. Writing a GUI just means reacting to messages rather than a more linear type console program.
You still do the low-level stuff, can't really get away from it nowadays.

Graphics meaning directx/opengl is another matter...

No, not OpenGL, DirectX or any other specialised stuff - just plain Windows GUI programming.

Thanks for all the replies btw. I think I'll grit my teeth and get the Iczelion tutorial done with - that should be enough.

dedndave

  • Member
  • *****
  • Posts: 8825
  • Still using Abacus 2.0
    • DednDave
Re: System programming vs graphic programming
« Reply #5 on: July 07, 2012, 10:31:29 PM »
we should all probably see a shrink   :P
finding pleasure in assembly language programming for windows may be an indicator of masochistic tendancies

at any rate...
GUI programming reminds me of writing old device drivers
instead of a dispatch table, you have a list of pre-defined messages that the system sends to a window
and - it's a very long list   :P

buttons, sliders, scroll bars, menus, and just about everything else are all treated as individual windows
although - the system handles most of the messages for you

Zen

  • Member
  • ****
  • Posts: 962
  • slightly red-shifted
Re: System programming vs graphic programming
« Reply #6 on: July 14, 2012, 03:17:57 AM »
Quote from: DAVE !!!
...We should all probably see a shrink,...
...Talk about incredible irony,...I AM A SHRINK,...
...And, assembly programming causes me great emotional distress and anxiety,...

OK,...BF2,...
I have to agree with you,...system programming is alot more fun than graphics programming.
But, once you become familiar with, say DirectX,...you can use all those techniques that game programmers use to create a graphics engine that you can use to demonstrate a visualization of almost any scientific process. You can even code a short interactive movie. You are only limited by your imagination. The coding can be quite tedious, though. Educational software often has extensive graphics presentations,...you can actually convey an immense amount of data graphically,...and, students find it more exciting than text.
Zen

Vortex

  • Member
  • *****
  • Posts: 2059
Re: System programming vs graphic programming
« Reply #7 on: July 14, 2012, 06:59:59 AM »
Graphics programming can be very interesting. Let's just imagine the fractals.  Before the computer era, it was impossible to imagine the graph of complicated functions.

Gunther

  • Member
  • *****
  • Posts: 3585
  • Forgive your enemies, but never forget their names
Re: System programming vs graphic programming
« Reply #8 on: July 14, 2012, 07:29:20 AM »
Hi Vortex,

Quote
Let's just imagine the fractals.  Before the computer era, it was impossible to imagine the graph of complicated functions.

Exactly. We wouldn't have seen the Mandelbrot Set, Julia Set, and all the other beautiful fractals.

Gunther
Get your facts first, and then you can distort them.

FORTRANS

  • Member
  • *****
  • Posts: 1062
Re: System programming vs graphic programming
« Reply #9 on: July 14, 2012, 07:54:35 AM »
Hi,

   Not to mention the allure of ray tracing.  Break out
the checker boards and shiny spheres.  Or, how about
a game of Conway's Life?

Cheers,

Steve N.

dedndave

  • Member
  • *****
  • Posts: 8825
  • Still using Abacus 2.0
    • DednDave
Re: System programming vs graphic programming
« Reply #10 on: July 14, 2012, 08:10:19 AM »
but....
(wait for it.....)
i'd rather play global thermonuclear war !
...with Ally Sheedy   :P

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6861
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: System programming vs graphic programming
« Reply #11 on: July 14, 2012, 01:01:14 PM »
I confess I am no great fan of Windows interface code but unless you want to be stuck with a console interface you have little choice. Once you get the swing of a message driven windowing system, the rest more or less makes sense. You get the swing of the API naming conventions with practice then you can look up most of what you need.

Apart from console IO, a GUI interface is not that much different, each "action" whether it be a button, menu option, standard or later common control, once you activate the control its mostly linear programming until the task is done. The later common controls have a strange interface through the notify message but there are enough examples around to be able to do most of them without any real problems.

If you start doing the more dedicated graphics tasks they are in fact much more like old DOS applications where you control the screen rather than the system controlling parts of the screen but the catch is you must draw it all yourself and that can be a lot of work.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

mywan

  • Guest
Re: System programming vs graphic programming
« Reply #12 on: July 16, 2012, 10:25:21 AM »
I actually like designing GUIs, though the best programmers (not me) tend to be awful at it. Even MS is going downhill on that front. Linux flavors could be the OS of choice if the desktop developers weren't so clueless, and this crap about GUIs not understanding the CLI will not fly. I'm on a mission to learn enough assembly to recreate a very small program I wrote that completely replaces all file associations in windows. It not only handles file open options for filetypes but also allows creating drawers of program in a taskbar toolbar, like a custom start menu at every icon. It can also redirect output so my text editors merely point to it for compile options, and I still get the the compiler output in the editors console.

It also worked well on Ubuntu under wine with some mild alterations. Ultimately it could be used as the core to allow a Linux desktop to interact without the monstrosities they call a desktop, with the CLI being the primary method of operation. From there the "brains" of other standard apps that come with different desktops can be stripped and shelled out in a system Linux was actually designed at the core to operate with. The pieces and parts to any desktops can be user selected entire separately from each other and interact just fine.

Assembly is a new beast for me, but I've already started down the learning curve. So I hope I can get by with some very dumb questions. Help files are often more confusing to me than the code they are describing. My mind is funny that way.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6861
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: System programming vs graphic programming
« Reply #13 on: July 16, 2012, 11:34:17 AM »
 :biggrin:

> Help files are often more confusing to me than the code they are describing. My mind is funny that way.

Sad to say its often the case that the help file ARE more confusing than the source code.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

Daydreamer

  • Guest
Re: System programming vs graphic programming
« Reply #14 on: July 17, 2012, 03:53:12 AM »
Hi Vortex,

Quote
Let's just imagine the fractals.  Before the computer era, it was impossible to imagine the graph of complicated functions.

Exactly. We wouldn't have seen the Mandelbrot Set, Julia Set, and all the other beautiful fractals.

Gunther
my favourite fractal is tall beautiful swedish blonde woman  :P  :greenclp: