Getting started programming?

[MNKyDeth]

So I have been starting to teach myself the 6502 assembly language from http://6502.org/tutorials/

I have went through most of the easy6502 and read a lot of the rest of the stuff there.

I can do basic little dot movements and color changes and seem to know how to use JMP, JSR and RTS. INC, IN.... etc.

So beyond these instructions and manuals where would be the next logical step to progress my learning of how to program for this console?


Edit: Wooops, thought I put this under the  PCE  Tool Game development. If a mod could move it, that would be great.

[elmer]

Congratulations on taking the step to learn 6502/6280 programming. 

It's not the easiest path, but you'll find that it'll completely open up the PCE's maximum performance for you, and you'll never look your PC/iPhone/RaspberryPI in quite the same way ever again. 

Do you know any other programming languages, or is this your first?

<EDIT>

One good thing to do (IMHO) would be to read more of the pages linked to from 6502.org, especially Garth Wilson's site that has a dumper-truck full of useful info/advice for 6502 programming http://wilsonminesco.com/links.html

You don't have to read-and-understand it all ... it's just a bunch of stuff that you can skim through to get immersed in how the 6502 is used in practice. Then you can keep on going back there later on as you learn more, to see specific techniques in use and learn new ones.

His page(s) on 6502 Stacks will probably introduce you to a whole bunch of useful info that you may not have seen yet.

[MNKyDeth]

Mostly what I have done is a little experimenting with some of the branches. I wrote a little endless loop that would cycle through the colors on the 4 or 5 memory areas the little windows provided me.

It would just increment the color by one, compare that color value and once it reached a certain value it would then cycle to the next part of the loop. Once it got to the end it would JMP back to the top and start all over again.

So I havn't done much but I can see how some of the stuff was and some of the confusing stuff of why certain things either worked or didn't.

This is this first programming language I have messed with for this long. I have been poking around at it for about the past month.

I have messed with ruby, perl, python and such but never got past hello world. The only thing I can do any scripting with right now is BASH on Linux.

[elmer]

This is this first programming language I have messed with for this long. I have been poking around at it for about the past month.

OK, that's not a problem at all, but I'm going to suggest that you take a little step backwards for a few weeks before getting back into 6502/6280 assembly language on the PCE.

Assembly language is absolutely great for creating fast programs, but the reason that it's not used much any more is that it's a very verbose, often hard-to-read, and fairly slow-to-write language.

The incredible power that is gives you comes at the cost of having to manually take care of all of the tiny details of a program.

I'm not suggesting that you ditch the idea of programming in it ... far from it. But I am suggesting that you *start* by tackling the problem from a different perspective.

My advice to you would be to read this thread ...
    
Learn to code through a series of challenges?
https://www.pcengine-fx.com/forums/index.php?topic=21498.0

... and then set yourself the task of writing that simple dots-on-the-screen Pong game in a high-level-language first.

You could either do it in PlayBasic like technozombie did, or do it in HuC if you really want to stick with the PCE.

You'll learn a lot of the basics of breaking down a task into some simple program steps, and you'll have the satisfaction of having something working that is your own code that you understand and can build on.

I'd recommend PlayBasic more than HuC at this point, because you'll have a decent debugger to use to see what's going wrong (and you will make a lot of errors, we all do).

You'd also have technozombie's version to look at for a comparison (AFTER you're done!).

If you do that, then you can take your simple Pong program, and figure out how to implement it in 6502 on the PCE.

The point is ... if you do it that way, you'll already have something that you understand to use as a template for your 6502 code.

For a fairly-novice programmer, it can be off-putting to start with the totally-blank-space that assembly language provides you, and know just where to start.

You might even take a middle step, and translate it from PlayBasic, to Huc, to 6502.

There are some good arguments for doing that.

[johnnykonami]

And please, don't forget to ASSBANK where you should have ASSCHUNK'D.

[MNKyDeth]

lol

Well, I started with the 6502 mostly because I do have a hard time sticking with a language. My spare time right now is filled with repairing these consoles and learning Russian.

I learn the programming in my free time at work. So it is fairly sporadic when I can sit down and concentrate on it but I really wanted to get into something with programming even if it is not extremely useful today.

These systems hold my interest far more than Java does so learning 6502 seemed logical.

[elmer]

Well, I started with the 6502 mostly because I do have a hard time sticking with a language. My spare time right now is filled with repairing these consoles and learning Russian.
...
These systems hold my interest far more than Java does so learning 6502 seemed logical.

The thing is ... these systems are basically blank when you turn them on.

You've got to understand the hardware, and know what you want to write.

They're not really something like an old C64 or Atari 800 BASIC environment where it's easy to "play around".
 
OK, if you want to dive in ... here's my cut down SCD template that I wrote to get some idea of how much of HuC and the Super CDROM BIOS I could easily disable and get around.

It's not documented, it's not overly efficient, and it's not self-contained (it still uses a couple of BIOS functions).

But it's the simplest PCE assembly language "Hello, World!" source code that I have to hand.

https://www.dropbox.com/s/pqaw0cptdfqk7kn/template_scd.zip?dl=0

Run "build.cmd" to assemble the source into a PCE ISO file, and then run "run.cmd" to run the ISO in Mednafen (if you've got Mednafen set up in the directory above).

To make any sense out of it all, you're going to need the PCE CD programming documentation from bonknut's site, and also the regular PCE hardware documentation (or Charles MacDonald's pcetech.txt file).

P.S. If you don't want to go blind trying to read Mednafen's default debugging font, you should download the build that I modified to use a larger font.

https://www.dropbox.com/s/6rpkviyhgihw4gt/mednafen-0.9.38.7-x86-elmer-2.zip?dl=0

There's a link to that file in another one of the threads somewhere, and I really do need to build a new one sometime soon with all of Rypheca's latest changes (like Saturn support).

[TurboXray]

Here's an old tutorial set I was working on back in '08:
http://www.pcedev.net/tuts/chapter_0.txt
http://www.pcedev.net/tuts/chapter_1.txt
http://www.pcedev.net/tuts/chapter_2.txt
http://www.pcedev.net/tuts/chapter_3.txt

 Has some stuff in there specific to PCEAS. Note: There's a typo that says 1023 cycles for the TIMER, but it's actually 1024 cycles.

 And here's two skeleton examples that were supposed to go with it (can't find the rest):
http://www.pcedev.net/tuts/example_1.zip
http://www.pcedev.net/tuts/example_2.zip


 Ohh! These cribsheets should come in handy (they are made for printing out on high res paper and put in a plastic protector; quick access at hand):
http://www.pcedev.net/blog/files/Otaku_no_PCE_cribsheet_page1_v1_0_3.png
http://www.pcedev.net/blog/files/Otaku_no_PCE_cribsheet_page2_0_1_4.png

[ccovell]

Great written tutorials!  I was actually winding up to make some PCE ASM tutorial videos for YouTube, since there seems to be nothing out there, and you already covered the basics in those text files!

The main thing that has held me back from starting with the basics is the dilemma of recommending either an old MagicKit since the library portion is still "small" and easy for a beginner to grok, or stay contemporary and use the PCEAS in the latest Artemio/Elmer build of HuC.
The latter appears to make at least 4 banks just for library routines, even just for ASM-only projects!

So, I'm leaning towards the former.  Anyone have any advice?  Or, are textfile tutorials good enough?

[TurboXray]

Would you be talking in the videos? The reason I ask, is not everyone learns the same way. Sometimes people need to hear someone explain it (visual and auditory), besides having the written explanations. For something like this, there's a steep learning curve in the immediate beginning because all the things involved (cpu, assembler itself, tools, video, audio, etc). It's calming to hear someone explain it in a lecture/tutorial style presentation, and helps with the anxiety and frustration of starting out.

[elmer]

Great written tutorials!

I agree, those are brilliant starting points! Thanks Bonknuts! 

So, I'm leaning towards the former.  Anyone have any advice?  Or, are textfile tutorials good enough?

IMHO, different tutorial examples should always be single source files that get more and more complex as the different concepts are introduced.

But there's an argument to be made for have 2 source files ... one for new code, and one for the code that you're building on.

I really don't think that there should be any use of library functions in assembly language tutorials.

IMHO, the whole point is to learn how to accomplish things yourself, and not just rely on some huge bank of hidden library functions.

I'm using Bonknuts's version of pceas, and that one doesn't seem to be including any library files/functions into the final ISO image ... an ISO, since I'm more interested in a minimal SCD template, rather than a minimal HuCard template.

Would you be talking in the videos?
...
For something like this, there's a steep learning curve in the immediate beginning because all the things involved (cpu, assembler itself, tools, video, audio, etc). It's calming to hear someone explain it in a lecture/tutorial style presentation, and helps with the anxiety and frustration of starting out.

It's a very steep curve for someone with no programming experience! There are so many new concepts to learn all at once.

I'd agree that a few good videos, with a friendly and calming voice, would be help immensely.

At least to cover the initial steps of getting set up, building the code, running it in Mednafen and then using the debugger.

One or two videos of the first few tutorial examples would help out, too.

I don't think that you'd need to explain what a CPU is, or how it works ... there are plenty of existing videos for that to link to.

[TurboXray]

Just to note: I didn't proof read any of these tutorial chapters. I'm sure there are affect/effect, where/were, and other grammatical mistakes - you'll just have to bare with it. Those chapters are basically just a stream of consciousness on the topic, with some attempt at ordering. They aren't meant for someone that has zero experience in assembly. At least some novice experience is required, even just the bare basics. But regardless of that, I've always found docs and tutorials to be helpful, even if redundant, because you'll reach that level at some point and it'll make more sense then.  (Note: it's weird to see my writing style from 8 years ago).


 A tutorial on using the mednafen debugger would be very valuable too. People tend to shy away from debuggers for some reason. But to me, they are immensely helpful in tracking down bugs. I even use it in my Java class to fix things like complex reference bugs (advance linkedlist stuffs). Too bad the instructors don't want to teach the students on how to use it - they say wait until later classes to learn how to use it. Meh. It's a valuable tool and should be learned how to be used early on.

[TurboXray]

IMHO, the whole point is to learn how to accomplish things yourself, and not just rely on some huge bank of hidden library functions.

I know there are two camps when it comes to this, but I totally agree. Especially for someone learning a system like this; having in-depth knowledge really is the key to working system on a low level. If you rely on fancy libraries, when starting out, you'll never really get the feel of things. Re-inventing the wheel, gives you intimate knowledge and experience of how the wheel works - vs someone who's only ever borrowed the wheel for whatever purpose. In higher level system development, that probably doesn't matter so much. But for the goal here, working with assembly, and limited resources (cpu, ram, etc), I think it's a must have strength.

[ccovell]

Yes, I would be talking in the video, no guarantees about calm or soothing-sounding voices.  I would start by talking about how the PCE works internally, using games as examples (in Mednafen) to show how RAM & VRAM are arranged & used, etc.

The idea of my tutorials is to get a person writing demos & the basic skeleton of a game, so I'm more leaning towards starting out with the early (<8k in $E000-) MKit library and stripping it even more (perhaps even in-video) & rebuild it like a hotrod. 

[NecroPhile]

Edit: Wooops, thought I put this under the  PCE  Tool Game development. If a mod could move it, that would be great.

Done.

Good luck with the learnenings.

[DildoKKKobold]

Well, I started with the 6502 mostly because I do have a hard time sticking with a language. My spare time right now is filled with repairing these consoles and learning Russian.
...
These systems hold my interest far more than Java does so learning 6502 seemed logical.

The thing is ... these systems are basically blank when you turn them on.

You've got to understand the hardware, and know what you want to write.

... Oh thank god for HuC

[OldMan]

... Oh thank god for HuC

Roflmao.
Learn real C, then come back to HuC.

[megatron-uk]

Yep, then running screaming away from it. 

It is easy to get something up and running, but if you do want to port anything or do something slightly approaching ANSI standard it's a big pain in the bum. One of the reasons I never got around to finishing the FAT filesystem driver for the Everdrive is the lack of struct support, so doing anything with the FAT table was a pain, calculating offset after offset for table entries... argh!

That and the lack of 'long' support. Yes, I know it is slow on a 8bit cpu, but my word, when you don't have 32bit integer support these days you do feel it!

[Arkhan Asylum]

As a side note, if you want good 6502

read Assembly Lines for Apple II, or Programming the C64 by Butterfield.

They are both 6502 books, and will teach you alot of important things.   The authors of those books are excellent at explaining things that will apply even to PCE

[ccovell]

Well, I've put together a video for a PCE assembly / tech tutorial: https://youtu.be/Hp6UaGcPXbY

This first video is just a general overview of the PCE hardware / CPU / VDC capabilities.

It took a while to get some quiet time around the house / get over technical obstacles (M$ f**kers!) but anyway.  This video is still unlisted, so feel free to post your comments & criticism here!

[edit] I recommend using a YouTube downloader to download the video at its highest size (720 HD or whatever) and watch it in your free time.

[esteban]

Covell: You had me at "PCE"...

[elmer]

Nice! 

[Gredler]

oh man this is awesome, thanks so much!

[TurboXray]

Dude..! Your voice is perfect. Keep doing these

[ccovell]

OK, if nobody has any problems with the content or delivery, then this thing's going live soon.

[ccovell]

My 2nd video (first half, anyway) is up:

I cover how some of the greatest PCE soundtracks get their rich sound.

[elmer]

I cover how some of the greatest PCE soundtracks get their rich sound.

That was really fun to watch, thanks!

It's great to see all of those clever techniques in use.

[ccovell]

Video 02, second half is up, making your own waveforms & sounds:

[XtoF]

@ccovell Quite nice and interesting videos! 

To answer the original question, what would you think about using the CC65 compiler/assembler suite, as an alternative to 100% hand coded ASM?
I never coded anything targeting the PCE, but I'm currently using it to learn the Apple II. Of course the performance of the compiled C code is bad, but I find it sufficient in the non-critical loops.
And it's easier to experiment in C than in ASM 

[elmer]

Learn real C, then come back to HuC.

Yep, then running screaming away from it. 

It is easy to get something up and running, but if you do want to port anything or do something slightly approaching ANSI standard it's a big pain in the bum. One of the reasons I never got around to finishing the FAT filesystem driver for the Everdrive is the lack of struct support, so doing anything with the FAT table was a pain, calculating offset after offset for table entries... argh!

That and the lack of 'long' support. Yes, I know it is slow on a 8bit cpu, but my word, when you don't have 32bit integer support these days you do feel it!

Well, it does have a lot more ANSI stuff in Uli's new HuC, especially "struct"s.

That should make it easier for newcomers to pick up and use (except that there's so little documentation on it).

And as Bonknuts pointed out, there are some 32-bit math functions down deep inside that you can call from assembly language.

But ... it's still *far* from compatible with true ANSI C code, and so you'd end up doing a lot of assembly work.

HuC is really a C-lite language designed for making games.

To answer the original question, what would you think about using the CC65 compiler/assembler suite, as an alternative to 100% hand coded ASM?
I never coded anything targeting the PCE, but I'm currently using it to learn the Apple II. Of course the performance of the compiled C code is bad, but I find it sufficient in the non-critical loops.
And it's easier to experiment in C than in ASM 

If you look, you'll find threads here about CC65/CA65.

There are so many things that I like about it, especially all the work that has gone into optimizing it, and into making it fully ANSI-compatible.

But, the price that has been paid in terms of code-generation complexity, and performance is a little bit too high for my comfort.

There's also little support in their libraries and system for the PCE's memory model and CD usage ... support of the PCE is at an early "work-in-progress" stage.

CA65 itself (especially when used with CC65) currently has some problems when it comes to zero-page variables that I've been trying to sort out with the guys there.

The root-problem itself is buried deep within the core of CA65, and I'm not sure when it will be fixed.

If you want to use C on the PC Engine, then I'd have to currently recommend HuC over CC65, especially after the work that Uli did on improving the ANSI-compatibility.

Unfortunately, the documentation on HuC, and how to get the best use out of it, is sadly lacking.

I'm a programmer ... I'd rather have a root-canal than write documentation, and this is one stand-out area where I've got to tip my hat to the CC65 guys! 


<EDIT>

I never coded anything targeting the PCE, but I'm currently using it to learn the Apple II.

BTW ... I ran across your blog a few weeks ago, and enjoyed reading it! 

If you choose to try writing something for the PCE, then you'll find it to be a much more powerful machine than the Apple II, and the Hu6280 processor really adds some nice intructions to the 6502 architecture that make it so much more pleasant to work with.

That's another problem that I have with CC65 ... it takes very little advantage of the 65C02 improvements, and has no optimization at all for the Hu6280 improvements.

[TurboXray]

Deleted posted. It belongs in its own topic and not really relevant for getting started.

[XtoF]

Thanks for these precise answers, you guys know your stuff! 
I'd never heard about HuC before, but now that I do, I'm going straight to Uli's Github!
   
As a matter of fact, I'm new owner of a CoreGrafX. I was always intrigued by this little machine, since I read a review of an imported cardridge of Parodius, back in the time. Now that I can play the actual game, I can say that I'm quite impressed!

So I intend to learn more details about the machine and roaming these forums seems like a perfect way to start!   

[elmer]

I'd never heard about HuC before, but now that I do, I'm going straight to Uli's Github!

You might want to look at my fork instead, there are a few important bug fixes.

I've updated the first message in this thread with a whole bunch of links to PCE information and development tools.

TED v2 Programming Notes
https://www.pcengine-fx.com/forums/index.php?topic=20120.0

So I intend to learn more details about the machine and roaming these forums seems like a perfect way to start!   

Welcome! 

You'll find a lot of useful and interesting stuff if you browse through the old threads.

[TurboXray]

Considering my last post was not really relevant for getting started, it got me thinking about "Getting into advance topics" for PCE. Something that could cover not only how certain data structures and algorithms fit more nicely with the 65x design in relation to the PCE, but also additional addon hardware and using that hardware (hysnc and advance VDC effects, arcade card, SF2 mapper, CD programming).

 I don't know if anyone besides myself has written code and demos for the SF2 mapper, but PCEAS inability to handle anything beyond 1megabit and since there's no linker system - it makes handling organization of data painful or wasteful. Injecting the data into rom and expanding it with external tools is not a problem, but putting those labels and attributes into the main source file remains a by hand process. Normally I don't complain about PCEAS not having a linker, but this is probably one case that I would argue otherwise. From my perspective, if you're going to develop a hucard game without the intent to sell in physical form, the SF2 mapper is a great choice. It just needs additional tools; both for HuC and for PCEAS.

 But yeah...

[elmer]

Considering my last post was not really relevant for getting started, it got me thinking about "Getting into advance topics" for PCE. Something that could cover not only how certain data structures and algorithms fit more nicely with the 65x design in relation to the PCE, but also additional addon hardware and using that hardware (hysnc and advance VDC effects, arcade card, SF2 mapper, CD programming).

More information and especially examples, would be great! 

I think that there's still a lot of "hidden" stuff about HuC, like your discovery of the __fastcall interface, that still isn't properly documented.

I'm definitely not the guy to do it ... but new PCE developers could really do with more documentation about HuC, and how to use it.

You know ... things like avoiding large local-variables, and making things global or static.

Stuff that isn't "normal" C practice.

Web-pages or a wiki that could be included in github would be perfect ... but blog posts or updates to Archaic Pixels would still improve things for everyone else.

Normally I don't complain about PCEAS not having a linker, but this is probably one case that I would argue otherwise. From my perspective, if you're going to develop a hucard game without the intent to sell in physical form, the SF2 mapper is a great choice. It just needs additional tools; both for HuC and for PCEAS.

You're welcome to help in the process of modifying the ASxxxx assembler/linker to be more-friendly for PCE usage, and more compatible with PCEAS.

I've already added Hu6280 support to it.

https://github.com/jbrandwood/aspce

And I'm happy to add other-people's improvements into my fork of HuC.

That's the beauty of github ... you can just create you own fork of the project, and then send me a pull-request when you've got something working.

[ccovell]

Episode 3 is up on my tutorial.  I don't get started coding yet, but I do take the necessary step of linking to programs & info sources.  Plus a bit about PCX files & 9-bit colour.

[elmer]

Episode 3 is up on my tutorial.  I don't get started coding yet, but I do take the necessary step of linking to programs & info sources.  Plus a bit about PCX files & 9-bit colour.

I've watched the whole thing now ... cool stuff, thanks for making that!   

It's a little bit slow-paced (IMHO) ... but there's really good stuff in there, although it's not quite how I'd personally choose to set things up.

It was funny to see that you're still using your Amiga toolset to create artwork. 

I know that I'm stuck in my personal comfort-zone, too ... with my Brief keymapping in the text editor, customized bitmap fonts in Windows, and use of grafx2 (Deluxe Paint, Deluxe Animator clone).

I really should be using ProMotion more, particularly now that there's a free version to recommend to people.

I was definitely a bit surprised to see you dropping stuff into the Windows directory instead of just editing the user path to add stuff ... especially because Mircosoft seem to be trying to lock down the Windows directory more-and-more with each revision.

**************

BTW ... does anyone know who runs the Archaic Pixels site, and how to get an account to edit stuff?

The whole site disappeared for a few weeks last year, but I see that it is back up now.

[ccovell]

Thanks for the comments.  Yeah, someone commented in YouTube to just get on with the programming, already, and I agree.  But I also wanted to point complete beginners towards where they could actually find and set up the assembler & documentation, because there isn't a single resource AFAIK on the web for this.

Heh, yeah, I could also have told people how to edit their path string.  :-)

I did mention the good programs like Grafx2, and I'm sure the Gimp is serviceable too. Maybe.  I am aghast at how people just do pixel art in MSPaint (and Photoshop to a degree)...

[Gredler]

Photoshop's art tools are unparalleled, I dug around for a long time but still haven't found anything that comes close to it.

If you could manually arrange indexed palettes easier there would be no need for anything else, but between Photoshop to make the art and gimp to clean up the palettes everything else seems less flexable and much less powerful.

Smart objects for tilemaps alone make it worth it, then layers and selection tools pffft fuggidaboutit!

[ccovell]

Deluxe Paint has layers too!  Well... up to 2 of them, anyway.   

[Arkhan Asylum]

Photoshop's art tools are unparalleled, I dug around for a long time but still haven't found anything that comes close to it.

If you could manually arrange indexed palettes easier there would be no need for anything else, but between Photoshop to make the art and gimp to clean up the palettes everything else seems less flexable and much less powerful.

Smart objects for tilemaps alone make it worth it, then layers and selection tools pffft fuggidaboutit!

I use PaintShopPro because Photoshop is a giant piece of shit that inverts PCX palettes for whatever dumb reason and it angers my asshole.


Also, it lets you manually arrange and deal with indexed palettes.

and doesn't tard out with RAW files.



and isn't $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

[ccovell]

I use PaintShopPro because Photoshop is a giant piece of shit that inverts PCX palettes for whatever dumb reason and it angers my asshole.

I did actually mention and show that in my video.  The P$-> PCX part, not your angered asshole, I mean.

[Arkhan Asylum]

lol.

It's horrible of them to do that to the PCX files.  Someone needs punched.

[TurboXray]

Thanks for the comments.  Yeah, someone commented in YouTube to just get on with the programming, already, and I agree.  But I also wanted to point complete beginners towards where they could actually find and set up the assembler & documentation, because there isn't a single resource AFAIK on the web for this.

Heh, yeah, I could also have told people how to edit their path string.  :-)

I did mention the good programs like Grafx2, and I'm sure the Gimp is serviceable too. Maybe.  I am aghast at how people just do pixel art in MSPaint (and Photoshop to a degree)...

I thought the video was fine. Some tutorials tend to race through things, and it can be frustrating for beginners IMO. I think the pacing in your videos is fine.

[elmer]

BTW ... when you said in the video that the necessary documentation was spread out all over the place ... well, I've just finished cleaning up the scans of the Hudson's English developer docs that have been floating out there on the interwebs for a while, including finally finishing off the splitting up and cleanup of the scan of the CD docs from bonknuts's site.

That makes a tidy little package of 10 reasonably-sized pdf files that cover all of the information that is needed to develop on the PCE in assembly-language, except for the SGX and Arcade Card.

IMHO, it would be good to have a single public website that you could point to in your videos that would have links to all the useful info, including Charles MacDonald's PCEtech and SGXtech documents, Bonknuts's Arcade Card document and PCE Cribsheets, and your PCEMon.

Now personally, I'd favor putting that page somewhere on esteban's tg-16.com, if he's willing ...

... partly because it's a short url, partly because he's already doing an amazing job of archiving a huge collection of PCE documentation, partly because his site is backed-up on the Internet Archive Wayback Machine at web.archive.org, and partly because he's a neutral 3rd-party, and then we don't have to worry about delicate developer-egos. 

[ccovell]

then we don't have to worry about delicate developer-egos.

NOW JUST WHAT ARE YOU IMPLYING, SIR?

;-)

[TurboXray]

and then we don't have to worry about delicate developer-egos. 

*looks up as he's laying out eggshells....* Hahaha

[Gredler]

I use PaintShopPro because Photoshop is a giant piece of shit that inverts PCX palettes for whatever dumb reason and it angers my asshole.

A giant piece of shit? It is a inconvenience to use gimp to clean up the palette, but I think it's quite hyperbolic to think photoshop worse than a minor headache when it comes to fixing palettes. As far as art creation goes, there's not a whole lot out there that can come close to competing with it; it's not even worth arguing, unless something can be shown to me by an artist to say otherwise. The tools in photoshop are unparalleled, and it's a world wide standard in digital art. It's a verb.

Also, it lets you manually arrange and deal with indexed palettes.

Gimp, you taught me this!

and doesn't tard out with RAW files.

I would consider PCX a compressed file, not a raw file. A psd is about as raw as you're going to get for art generation purposes.

and isn't $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

I upgraded my CS6 (attained very affordably) with a monthly 10$ subscription to CC. What I get with that $10/mo pays for itself hand over fist repeatedly.

Compared to the collectards around, and the cost of an average lunch or dinner where I live, that's not a terrible price. I'd drop that down to a dollar sign or two.

I'd love to see a better solution that CC/CS6 + Gimp, but maybe my tenure in photoshop outweighs the headaches of opening another program to palette organize my art.

[Arkhan Asylum]

A giant piece of shit? It is a inconvenience to use gimp to clean up the palette, but I think it's quite hyperbolic to think photoshop worse than a minor headache when it comes to fixing palettes. As far as art creation goes, there's not a whole lot out there that can come close to competing with it; it's not even worth arguing, unless something can be shown to me by an artist to say otherwise. The tools in photoshop are unparalleled, and it's a world wide standard in digital art. It's a verb.

You realize PSP is often suggested as an alternative to Photoshop, right?  It's actually a quite powerful program with the same sort of tools and features as Photoshop.   In addition to correctly handling palettes.

Besides, Photoshop is generally only an "industry standard" because it's shoved down everyone's throat, and up their ass, simultaneously.   

...and is often taught/provided in university, and thus people just stick with it because they were taught it, got it cheap, and don't want to pay more money.

Go try PSP out.  There's a free trial. 

To that note, many artists aren't using Photoshop anymore.  They're using PSP, or Clip Studio, or that other one that I forget the name of. 

mostly because everyone got collectively tired of Adobe charging out the tits for their software, and then moving to a subscription model.

I took a survey of ~20 artists at an artist alley at a con about 6 months ago.  1/20 were using Photoshop, and he was only using it to touch up someone elses work, because "he already had a copy".

I would consider PCX a compressed file, not a raw file. A psd is about as raw as you're going to get for art generation purposes.

Cool.  I am talking about the .RAW file format.    Another format that is handy when working on old platforms.   MSX uses this.   

I am pretty sure a RAW is about as raw as you're going to get, as it's literally raw data.   

I upgraded my CS6 (attained very affordably) with a monthly 10$ subscription to CC. What I get with that $10/mo pays for itself hand over fist repeatedly.

Compared to the collectards around, and the cost of an average lunch or dinner where I live, that's not a terrible price. I'd drop that down to a dollar sign or two.

I'd love to see a better solution that CC/CS6 + Gimp, but maybe my tenure in photoshop outweighs the headaches of opening another program to palette organize my art.

I bought PSP X9 for 45$.    in 5 months, I won't have to pay 10$.   

I'm sorry, subscribing to art software is kind of stupid.   What do you get for that 10$/month that was lacking when you weren't subscribed?


Also:

Elmer, lol, wtf do programmer egos have to do with hosting a zip file of PDFs?   I'd like to think nobody is that much of a dipshit that they'd sabotage and take down documentation out of spite. 

It would be nice to host them all in a place where they're viewable online.

[Gredler]

Nice I will check PSP out. Last time I used it I was like 10 years old and it was rad vs paint, but once I got Photoshop I never looked back, maybe I should thanks for the suggestion.

I didn't realize RAW was an actual file format for images, I was assuming you are using it as a adjective for a file that is at its rawest and most flexible state - it makes more sense to be a  file containing "raw data." Apologies for the symantics confusion.

I find it surprising that you are debating that Photoshop is not the standard because of its proliferation in the professional art development implementation. 

They teach Photoshop at school because it's the standard, and if you try to get a job in most digital art fields and say "PSP" they will laugh at you if you even get an interview without Photoshop on your resume.

Hobbiests yeah I can see it being all sorts of random apps and tools, but the vast majority of studios just get Adobe software, Photoshop for raster and illustrator for vector (and now zbrush for zpixels).

As for the subscription it's for a lot of features you can read about them on the product page, I take advantage of quite a few of them and also just like the constant updates support and expansion of the program. I could have lived with cs6 for a long time, but like I said the 10$ a month pays for itself easily.

Seriously dude, maybe Photoshop sucks for making art on these platforms and I will happily look into other options, but so far nothing competes with Photoshop and for all modern digital raster images it can't be beaten. 20+ years of bias leans me towards Photoshop for sure though, so I am open ears for retro tools to do pce work with

Edit: just looked into PSP, looks cool man I will try the demo this week for sure. What version did you get for 49? It's on sale right now for 79.

I am surprised to hear Corel owns it now! I used PSP first, then Corel draw and hated that, then sent back to PSP until I got Photoshop 2.0 from a BBS I didn't own a copy until cs2, then upgraded to 3, and 6, and CC. I've made my living off Photoshop since middle school, so buying it always made sense.