Getting started programming?

[ccovell]

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

NOW JUST WHAT ARE YOU IMPLYING, SIR?

;-)

[Bonknuts]

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 a$$hole.

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]

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.

[Arkhan]

I've actually had PSP since 7.    I upgraded mine for 45$ or whatever.


The other reason I think Adobe sucks is basically what they've done to themselves.

Adobe f*cked up CoolEdit, and turned their software into this juggernaut of nonsense.

Don't you have to login to use the subscription based one?

[Gredler]

You don't have to be online, and it's a one time login. You have to be online for updates obviously and that probably checks your credentials but it's never asked me to logon after the initial installation.

I can see your trpedation about Adobe because of audition/cooledit. I kinda feel the same way about Autodesk and Maya, but after acclimating to max by need of a job I had, I found that Maya (and max) getting shared features between the two makes them both better. These megacorps be shitting on our habits, it's rough dude I feel ya


I used PSP either 1 or 2, can't remember very well. I used it to draw Mario

[ccovell]

Two new videos, one on CPU instructions, and the other, we get started writing some code:

[Pokun]

A beginner tutorial for assembly, that's just what PC Engine needs!

Just finished watching them all and they are great tutorials! A bit slow at first but you show a lot of things that's not so easy to show in a written document so that's cool, and when you finally get to coding it's just great.

I'm looking forward to see more.

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.

Hmm why can't it handle bigger than 2 Mbit if I may ask?
Now when cc65 handles Hu6280, what about using ca65 and the linker ld65 from the cc65 suit? That's what I'm doing for Snes and it's one of the most popular assemblers for Nes (although I'm using asm6 for Nes because it's simple like PCEAS). For newbie tutorials, PCEAS2 is probably the better choice though.

[elmer]

Hmm why can't it handle bigger than 2 Mbit if I may ask?

I suspect that Bonknuts means 8Mbit (1MByte), which is the largest cartridge size.

I know that the Catastrophy guys are using well over 1Mbit (128KByte).

It can probably be extended to handle larger cart sizes, but nobody has done so, probably because nobody  has needed the extra space.

Now when cc65 handles Hu6280, what about using ca65 and the linker ld65 from the cc65 suit? That's what I'm doing for Snes and it's one of the most popular assemblers for Nes (although I'm using asm6 for Nes because it's simple like PCEAS). For newbie tutorials, PCEAS2 is probably the better choice though.

CC65 is already usable on the PCE, I've used it.

It's just missing a lot of usability stuff like libraries, and it doesn't take any advantage of the Hu6280 or the memory segmentation/paging.

CA65 already understands Hu6280, but it has a problem with our zero-page being at $2000 instead of $0000.

You can see a long discussion of my attempts to talk to the guys about that on their github bug-tracker.

The discussion stopped a while back, and I don't know if there's ever going to be an official fix ... there are some deep-seated problems in Ulrich's original CA65 code-design that will take some fixing.

So, for the moment, PCEAS really is the best choice available (IMHO).

And while HuC lacks a lot of the code-optimizations in CC65, it does a number of things better (for the PCE), and its library is helping folks make games today.

[Pokun]

It can probably be extended to handle larger cart sizes, but nobody has done so, probably because nobody  has needed the extra space.

So PCEAS simply rejects assembling larger HuCard ROMs than 1 MB? Sounds like another mostly pointless restriction like the forced 8 kB banks thing that was fixed in PCEAS2.

CC65 is already usable on the PCE, I've used it.

Yes, I was mainly discussing the assembler CA65.

CA65 already understands Hu6280, but it has a problem with our zero-page being at $2000 instead of $0000.

You can see a long discussion of my attempts to talk to the guys about that on their github bug-tracker.

The discussion stopped a while back, and I don't know if there's ever going to be an official fix ... there are some deep-seated problems in Ulrich's original CA65 code-design that will take some fixing.

So, for the moment, PCEAS really is the best choice available (IMHO).

I see, it would be useful if it simply had an assembly directive to relocate the Zero Page to wherever the user want:

  .zploc $2000  ;tell assembler where the Zero Page is

And then you are done with it for PC Engine. Would be useful for 65816's relocatable Direct Page as well.

Thanks for the explanation though. It sounds like CA65 isn't really ready for the Hu6280 yet, I guess I'll stick to PCEAS2. The main problem I have with it so far is that it doesn't have a complete readme file. The documentation that comes with Magicengine and HuC doesn't seem to be complete for PCEAS.

[elmer]

So PCEAS simply rejects assembling larger HuCard ROMs than 1 MB?

Errrr ... What would you like it to do? 

This is no standardized mapping scheme for > 1MB HuCard ROMs.

There was only one > 1MB HuCard ROM ever released, and nobody has implemented its mapping scheme in a homebrew HuCard release (that I know of).

Sounds like another mostly pointless restriction like the forced 8 kB banks thing that was fixed in PCEAS2.

I'm sure that the original PCEAS devs thought that it made sense.

It didn't really ... because they already handled an incbin that crossed bank boundaries, but ... oh, well.

BTW, PCEAS2 does NOT properly fix the problem. 

http://pcedev.wordpress.com/2012/02/06/new-tg16pce-assembler/

Opcodes that cross 8k bank boundaries no longer create an error and stop assembling. That is to say, if one or more opcode’s byte cross that boundary. Now it will generate a warning instead, but assemble correctly.

Well, PCEAS2 doesn't fail when a bank is crossed, that part was definitely fixed.

But it doesn't actually assemble correctly.

None of the bytes that cross the boundary are written to the new bank, and they just stay at the default $FF.

You can see that if you edit his test2.asm, line 102 and change "lda #$FF" to "lda #$23" and run go.bat.

   99           5FFF        .org $5fff
  100  01:5FFF            cross_bank:
  101  01:5FFF            .loop
  102  01:5FFF  A9 FF       lda #$23
  103  02:6001  80 FC       bra .loop


I'll be fixing this in the next build of Uli's HuC, because it's messing up Huzak when there's tune data larger than 8KB.

I see, it would be useful if it simply had an assembly directive to relocate the Zero Page to wherever the user want:

  .zploc $2000  ;tell assembler where the Zero Page is

And then you are done with it for PC Engine. Would be useful for 65816's relocatable Direct Page as well.

That's what they've been trying to implement.

But there are some deep-seated design choices (I'd call them "mistakes") that get a bit confused when $00xx is not a zero-page location.

[Pokun]

Heh well it kind of makes sense to assume that the Zero Page is always page 0. I guess Hudson should have called it the $20-page or something. I guess that's why they renamed it the Direct Page for 65816 in the first place, since it's relocatable to other pages.

So PCEAS simply rejects assembling larger HuCard ROMs than 1 MB?

Errrr ... What would you like it to do? 

This is no standardized mapping scheme for > 1MB HuCard ROMs.

There was only one > 1MB HuCard ROM ever released, and nobody has implemented its mapping scheme in a homebrew HuCard release (that I know of).

I see, so then it's not an artificial rejection but rather a matter of running out of addressing space.
Ideally it still should be possible to make games using the Street Fighter II' mapper somehow though.

Sounds like another mostly pointless restriction like the forced 8 kB banks thing that was fixed in PCEAS2.

I'm sure that the original PCEAS devs thought that it made sense.

Yeah well it's not as much a matter of making sense as a matter of putting unecessary restrictions on the assembler. There's no telling when you need to do something different than the usual way, and then these kinds of restrictions get in the way. That's why I think giving warnings and making things optional is the way to go.
For NESASM (the Famicom version of PCEAS if I understand things correctly) the forced 8 kB banks makes zero sense though (unless you are using certain mappers) which is why people dislike it over at Nesdev.net.

Well, PCEAS2 doesn't fail when a bank is crossed, that part was definitely fixed.

But it doesn't actually assemble correctly.

None of the bytes that cross the boundary are written to the new bank, and they just stay at the default $FF.

Oh I had no idea it wasn't really fixed. I've yet to make a program that is big enough to need more than one ROM bank of code.

So which version of PCEAS is the one to go with? I'd prefer an assembler that doesn't create extra banks and stuff that you don't tell it to. I'll create my own libraries.

[elmer]

Oh I had no idea it wasn't really fixed. I've yet to make a program that is big enough to need more than one ROM bank of code.

So which version of PCEAS is the one to go with? I'd prefer an assembler that doesn't create extra banks and stuff that you don't tell it to. I'll create my own libraries.

AFAIK, no version of PCEAS automatically creates or uses extra banks ... by itself.

If you *choose* to use the "proc" functionality in PCEAS, that was designed for HuC, to allow for the automatic relocation of functions into different banks ... then "yes", you'll end up with extra junk, and you'll be locked into HuC's uncommon memory-map.

If you avoid "proc" functions, and just code as normal in regular assembly-language, then PCEAS has no overhead.

I use the latest version of PCEAS, from the latest version of HuC that I've posted, and I just code in pure assembly language without using any of the HuC or MagicKit libraries, or functions. or memory map.

So, although I'm obviously biased, I'd recommend that you use the PCEAS and selected equates from the latest HuC, and just ignore (or delete) all of the other files in the download.

If you're programming in assembly-language, then just avoid huc.inc and startup.asm, they're a mess! 

At least then, you'd know who to come to with any complaints. 

Uli added various enhancements to bonknuts' changes in PCEAS 3.22, and I've added more of my own since.

Or you can just look at the most recent patches in github, and apply those to bonknuts' 3.22 source files, if you'd like to go that route.

[Pokun]

Ah so Bonknut's improvements are already in these HuC forks. Good, I'll just grab the assembler. Thanks!

Edit: OK I'm using this one.