I like ASM... What's similar?

[Jiggers]

I've had a lot of fun working on my FF1 hack over the last year. Coding random little things like a random chance for one class to fall asleep in battle, a sound test screen, learning how graphics printing works to make a proper intro screen and all that...

Unfortunately, my drive to work on this particular project is dying fast these last few days. While I could slice away the elements that are causing my discomfort, I keep feeling like I could do so much more if I had less limitations (mainly sprite size, resolution, amount of background tiles and colours available at a time.) Even though I loved working within the NES's limitations for other things! It helped me learn and adapt! But a game needs art and my artist friends are not pixel artists, nor do they want to be.

My ideal situation would be working with ASM-type coding on a small PC game, Windows 7 compatible. Before I started learning ASM stuff, I couldn't wrap my head around any other languages I looked at. Object-oriented, I think they're called? Maybe I could handle them now, but I don't know. Whenever I try to use RPG Maker, I feel helpless and lost; I feel like its maybe better for people who are artists, who can make their own assets and draw maps and characters. I don't want to fight its engine to act like how I want it to act. I think I might enjoy writing my own. Control how maps work, the size of characters and enemies, how dialogue windows open, how the menus change things. I kind of just want to play around with that stuff more than design maps and stories, at the moment.

So I'm looking for suggestions... either a coding language close to how ASM works, with enough of a background engine already in place that I don't have to code how it interacts with Windows to produce sound and pictures--like, the NES has registers, you just put values in them to have stuff happen. I don't have to have to code the registers themselves, if that makes sense!

Or perhaps I should use some GameMaker type thing, one that's not as restricted as RPG Maker is with its presets and resolution?

[Disch]

Write an NES emu.

I'm not joking.


It's one of THE most fun projects ever.  And it really gets you a ton of insight into low level architecture (though not all of it is applicable to modern machines -- but the fundamentals are similar enough).

There's a shit ton of documentation available, and a huge community to help you through any hiccups.

Even if you end up using a higher-level language like C# or Java or C++ or even Python -- the vast majority of the coding is back-end logic of simulating system hardware, so it "feels" low-level.

Also you don't need to worry about creating any graphics or music or anything -- all that shit comes bundled in the ROM.  You just have to play it.



EDIT:

I originally started with an NSF player, since that only requires emulating the CPU/APU and VERY basic memory stuff.  A full emu adds mappers, a bunch of weird timing details, and the PPU... which is a lot to take in.  Starting small with just the audio is a pretty good way to baby-step into the project.



Or if NES isn't your thing, try an SPC player.  Also good docs available for that.

[Jiggers]

Mmm, I dunno. I still want to make a game!

I had fun making this intro sequence. The other day I fell asleep while thinking of how to print one letter at a time, how to fade in a sprite, then print the background, have the sprite move on and fade in the next letter... and when I woke up the next day, I made it work.

https://www.youtube.com/watch?v=i7dTcTwHolU&feature=youtu.be

Adding hiding and turning the ailments into icons, fixing up the battle screen, was another couple weeks of happy problem solving:

https://imgur.com/a/IYowUYW

At the moment I'm trying out this Godot engine a friend recommended, but I'm already getting frustrated and confused, just trying to add an image to be used as a tileset. Gotta go back to the very basics so I can even understand the tutorial.

What I love about my FF1 project is how simple everything is when you get down to it. Everything has a place. A tile has a spot in the ROM. Find it, load it into memory, find the part that prints tiles, tell it where that tile's spot is, do all the finicky PPU updating and scroll-setting, and the tile is displayed next frame! Step by step by step. Small, small steps. LDA, STA, JSR, RTS. And all the code is laid out like a novel, each bank a different chapter. There's no fiddling around with a ton of semi-colons and parenthesis and long, long lines filled with underscores for spaces.

...maybe I shouldn't abandon NES development. Just start my own game, instead of fiddling with this one. But I want more colours! Bigger sizes! Maybe SNES?

I know whatever language I work with next, I'll have to start almost from scratch. I just wish I could explain the difficulties I have in understanding anything else. Maybe I'm trying to learn too much at once...?

Still, I owe you so much for helping me get this far. I never thought I'd like coding! Let alone start thinking that I might prefer it to playing games some days...

And not to discount your suggestion! An NSF player sounds great, I'd actually love to be able to make a tool that converts an NSF to midi better than the one tool I already found. I just have no idea where to start with what language to learn to make a Windows application.

[Disch]

There's no fiddling around with a ton of semi-colons and parenthesis and long, long lines filled with underscores for spaces.

Don't know which language does that  =P

But Java and C# both have a thing with a REALLY huge core library, and so stuff you need is buried in really long namespace qualification  (ex:  System.Out.PrintLine .. and that's even one of the shorter ones)

...maybe I shouldn't abandon NES development. Just start my own game, instead of fiddling with this one. But I want more colours! Bigger sizes! Maybe SNES?

There's a charm to retro dev.  And in a way, the limited hardware helps reign in your ambition.  When developing for a modern platform it's really easy to get carried away with too many ideas.

On the other hand, if you make something for PC you can throw it on steam and maybe make a few bucks.

Shruggles.

I know whatever language I work with next, I'll have to start almost from scratch. I just wish I could explain the difficulties I have in understanding anything else. Maybe I'm trying to learn too much at once...?

You absolutely will not be starting from scratch.  There's a big different in style between retro assembly and modern OO languages, but the fundamentals are largely the same.

LDA/STA becomes '='
CMP becomes '=='
JSR SomeLabel becomes 'SomeFunction();'

All these core asm concepts have DIRECT equivalencies in C-like languages, because C was designed to basically be portable assembly -- and all the languages it spawned took heavy influence from it.



I would say give it another shot.

If you want bare-bones, close to low level, "I want to do build everything myself from the ground up" -- pick up C or C++ with the SDL library....  or C++ with the SFML library... or maybe even Python with the PyGame library

If you want an existing working engine that does the heavy lifting for you and allows you to quickly mold it into your own game, pick up C# and Unity.


Note the biggest hurdle in ALL of these instances is not learning the language, it's learning the library.  The more complicated the library, the more there is to learn.  So Unity will have a bigger learning curve, but will also have the bigger payoff in terms of what it will allow you to accomplish.

And not to discount your suggestion! An NSF player sounds great, I'd actually love to be able to make a tool that converts an NSF to midi better than the one tool I already found. I just have no idea where to start with what language to learn to make a Windows application.

Literally any modern language will get you to a windows application with relative ease.  C/C++ environments are probably the hardest to set up because they're a touch archaic, but I'd still recommend C++ for emu development --- maybe because I have a bias... but building a hardware simulation in C++ is so damn sexy, where other languages kind of feel chunky.

But if you want to do anything with a GUI, C and C++ are both terrible and I'd probably avoid them.  Then again I haven't found any language that doesn't suck when it comes to GUIs... so... *shrug*  I think GUIs just suck in general.



I also hear very good things about Rust but I haven't used it and don't know anything about what libs are available for it.

And if you want to build up a resume and make yourself marketable, you might want to consider Go (GoLang) -- but again I can't speak to it.

[Squall_FF8]

Coding random little things ...
My ideal situation would be working with ASM-type coding on a small PC game, Windows 7 compatible. Before I started learning ASM stuff, I couldn't wrap my head around any other languages I looked at. Object-oriented, I think they're called? ...  I think I might enjoy writing my own. Control how maps work, the size of characters and enemies, how dialogue windows open, how the menus change things. I kind of just want to play around with that stuff more than design maps and stories, at the moment.

You have all the symptoms to become a good professional developer

Forget about RPG Maker, Game Maker and whatever maker - that is a milk for babies, you have grown up enough to start with a real food. For that you need a good high level language for development. You have pretty much have only 2 options: C based or Pascal based. For C based - C/C++/C#. For Pascal - Delphi/Free Pascal/Lazarus Pascal. And that choice should be done by you alone, without a pressure. Since for C based languages you probably have heard enough, let me share few things about Pascal:
- structured object oriented
- extremely easy to learn - easy to read the code
- if you know x86 assembly - just write: asm ... and you are home - no need for external compilers of asm, no need for intermediate files like .obj,...
- probably the fastest compiler - compared to all other languages
- it produce small executable code. No need for external DLL, no need for frameworks that install for 30min-1hour
- ofc, you can produce a code that rely on external dll's if that is your thing 
- Register call convention - the fastest way to call Procedure/Subroutine with params on x86 world
- Visual programming (Delphi) - just drag-N-drop components and your UI is done
- constantly developed
- you can write native applications for Android/MAC OS (no java BS)...
- you will have access to all libraries used in games - DirectX, OpenGL, SDL,...

I can go on and on, but the point is you will be able to start fast, use few clicks to create a complete application. Later on when you learn more you will be able to add more code and control manually more things. You will have a powerful tool that can do everything that is possible to be done (many of the scripting languages are quite limited)

[Bregalad]

Write an NES emu.

I'm not joking.

Before considering developing your own NES emulator, ask yourself if your efforts may be better spent helping out those who already have emulators in development!

[Disch]

Before considering developing your own NES emulator, ask yourself if your efforts may be better spent helping out those who already have emulators in development!

My answer to that question would be "no".

I actually kind of dislike that koitsu stickied that thread --- it's as if he's trying to discourage people because he's worried about there being "too many emulators" -- as if that makes any kind of sense.  And he seems to be assuming that the emulator is the end goal -- which it almost never is.  Or that the NES emu dev scene is hurting for quality contributors, which it absolutely isn't.

[FAST6191]

I find RPG maker et al rather stifling if I am wanting to code things. As an ultra crude prototyping setup it is interesting though.

Anyway what about instead of going higher level you go lower. Plenty of electronics out there to play with. It is not my thing but pinball seems to be an in for many people.

[Valendian]

Check out this guys channel it is great for showcasing the technology behind old school games.

https://m.youtube.com/channel/UC-yuWVUplUJZvieEligKBkA

He targets those videos for complete begginers and its not asm but c++. But it will introduce you to c++ while having fun

[Squall_FF8]

Check out this guys channel it is great for showcasing the technology behind old school games.

Speaking of that channel I strongly recommend watching: 8-Bits of Advice for New Programmers

[Jiggers]

I think I got a long way to go still. I gave Lazarus Pascal a try, fiddled with it for a while to try to make my own little thing... it didn't go so well. I had better luck following a tutorial (one that didn't assume I already knew everything, but still missed a few obvious steps that were not obvious to me), but I still didn't really understand what it was doing. Then my neck started hurting so I stopped.  I guess loading a .bin file and trying to read the hex numbers until I run into a $90 was still too deep-end for my first couple days. I got as far as loading the file...

Pascal really seems like what I want though! But I guess I should try C as well.

I'm also really interested in the Turbo Grafx 16 now. It seems like it'd solve my issues of not having enough colours and screen space, while still being tight enough with its 8-bit CPU to be familiar. I've just been so spoiled by Disch's FF1 disassembly! I've never dabbled in mechanics, but I figure most people learn from working on old, finished (if broken) cars, not building their own from nothing. Reading and writing is like that, too, isn't it? I know that's how I also learned to compose music, by studying midi files to see how it all comes together, then emulating those concepts... So wish I could find something like that for any TG16 game, see how the code communicates with the system.

I'm still struggling with some basic math stuff, so I think I need to make a new thread about that.

Thank you all so much for the suggestions!

[Squall_FF8]

I gave Lazarus Pascal a try ...
Pascal really seems like what I want though! But I guess I should try C as well.

I'm glad you choose Pascal. Lazarus has free IDE - it seem pretty similar to Delphi.
You can rely on me: if you have questions, or topic to discus - I will gladly help. In the beginning is important to discuss what you have learned, that way it will stay as long-term memory and you will easily understand the subject, so bring it on 

[bailli]

So I just skimmed through this thread, but this might interest you: http://www.raspberrypi.org/archives/4300

[RyanfaeScotland]

Hey Jiggers, can I ask what it is you like about the development?

I want to recommend Unity but it doesn't make a lot of sense if your main passion is for ASM!

There is a wealth of Unity tutorials online so I won't bore you with the details but it is basically a game engine / development environment written in C# and it lets you do lots of super awesome things very quickly and with the right passion and commitment you could develop genuinely amazing things. However, it is C# and not ASM!

But Java and C# both have a thing with a REALLY huge core library, and so stuff you need is buried in really long namespace qualification  (ex:  System.Out.PrintLine .. and that's even one of the shorter ones)...

Do you find that a real issue Disch or are you just pointing it out for a contrast? You know you can add 'using' statements to the top right? You don't have to type the whole path out every time.

...it's as if he's trying to discourage people because he's worried about there being "too many emulators" -- as if that makes any kind of sense.  And he seems to be assuming that the emulator is the end goal -- which it almost never is.  Or that the NES emu dev scene is hurting for quality contributors, which it absolutely isn't.

Aww man but we could potentially achieve so much more if more of the community / people learning worked this way. Imagine if instead of having 9 talented programmers working on their own code we had them all contributing to the same one? It could be disastrous of course but it could be beautiful as well!

[Jiggers]

Hey Jiggers, can I ask what it is you like about the development?

I want to recommend Unity but it doesn't make a lot of sense if your main passion is for ASM!

I have no idea how to answer this! But here are some random thoughts. A conversation I had a few months ago:

[16:40] Jiggers: What's with programmers hating simple English
[16:40] Friend: I think you understand more than you let yourself believe
[16:41] Friend: It makes sense once you're steeped in the code
[16:41] Jiggers: It just takes so long for it to click...
[16:42] Friend: You'll get there
[16:42] Friend: You practically got one of the hardest languages down and that one's basically hot nonsense
[16:44] Jiggers: What! Its just numbers in spots.
[16:44] Friend: It's even less English tho! It's like a secret code!
[16:45] Jiggers: There is some shorthand, but that's what makes it simple.
[16:45] Friend: It's basically a numbers station
[16:45] Jiggers: LDA is just Load Bucket A
[16:45] Jiggers: Pouring numbers into different buckets like water... making sure they don't spill over, and when they do, C is your mop!
[16:46] Jiggers: Mop that number up and squeeze it back into another bucket! Or dump it out entirely!
[16:46] Jiggers: I RARELY have to deal with parenthesis and the only time I need a semi-colon is to tell myself what I just did.
[16:46] Friend: Hot nonsense
[16:46] Jiggers: XD
[16:47] Jiggers: sometimes you can put the numbers into shapes.
[16:47] Jiggers: lut_TitlePalette:

  .BYTE $00,$00,$00,$00,$00,$00,$00,$00
  .BYTE $00,$55,$50,$50,$50,$50,$10,$00
  .BYTE $00,$08,$0A,$0A,$0A,$0A,$02,$00
  .BYTE $FA,$FA,$FA,$FA,$FA,$FA,$FA,$FA
  .BYTE $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
  .BYTE $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
  .BYTE $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
  .BYTE $FF,$FF,$FF,$FF,$FF,$FF,$FF,$FF
[16:48] Jiggers: This tells the NES what palette to use for every 4x4 block of tiles on the screen.
[16:48] Jiggers: So the bottom half uses Palette #4
[16:48] Jiggers: $00 is #1
[16:49] Jiggers: $55 is #2
[16:49] Jiggers: Simple stuff like that!
[16:49] Friend: That's so complicated and microspecific

Microspecific might be the thing that draws me in. I like knowing what the code I'm fiddling with is doing, and why its doing it. I like that NES programming is basically one freakishly long branching-pathed loop. Being able to inject another branch at the spot where it checks what buttons were pressed, then going through all the steps to change what's displayed on the screen, setting up a new loop of "draw, check input, keep music going"...

I like the little project environment I have. Every bank is its own Notepad++ file. When I compile and a bank is full, I know I gotta re-organize and think about a better way to let the loops access what they need to. The core loop is in one file, music driver is in another, battle logic is in another... That keeps all the different aspects of the game just separate enough to stay organized. I don't like having a lot of files and tabs to search through. I like the way variables are named and given "physical" space to exist. I kind of view the whole project as a colouring book, where I can take every grain of crayon and shift it around to fill in the lines, where the lines are the NES's limitations. 'This square has too much red, so take all the red and put it in a new square, and that leaves more room in the old square for the green to do more interesting things.'

I guess I don't like the concept of things being "under the hood".  While actually designing a game, that might be preferred, but what was intriguing me at the time was the whole idea of what IS under the hood. How does a program tell the screen to draw a black pixel exactly 400x400 pixels away from the top left pixel, and once I've worked out how to do that, what can I do with that information to make something fun?

On the other hand, things like programming a physics engine, nah, that's too much math. So, I definitely would prefer SOME things be pre-built for me.

I've been taking a break from everything code for a while, but its been itching at me this week, and I want to finish up my FF1 project before I really try to delve into anything new. However, I think I might still have Unity installed; I did the first two steps of a roguelike tutorial a year or two before getting into ASM, and don't remember why I stopped. (I think it was because I started making my own graphics instead of using the basic stuff the tutorial was having me use, and then I got distracted with that...)

I can't decide if I want to make a short side-scroller game about crawling on the text inside a book and absorbing certain words to use as weapons... or a roguelike where each dungeon is only 5 floors and you're basically killing a giant Shadow of the Colossus beast from the inside... Or just a simple RPG with lots of fun classes and skills...