Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation on 09/03/20 in Posts

  1. 4 points
    One more thing (sorry for the double post, this occurred to me a few minutes too late, haha). You mentioned that you're not much of an artist so you'll design the game with simple graphics. That makes sense, but the other route would be to find an artist and team up. Not only will the game look nice, but doing so will have the arguably more important benefit of giving you experience working on a game with other people. When it's all done and you begin looking to join an indie studio, your artist friend can write you a letter of recommendation vouching that you're a good person to work with, you understand how to work as part a team, etc., all of which will be attractive to smaller studios.
  2. 4 points
    So, maybe a person needs a few loose screws to stay in the games industry in the long-term, but I want to try and offer some positives about the game industry, reasons that I have stayed for as long as I have: I found a great studio that looks after its employees. That's not to say that Volition has never crunched, and never made mistakes along the way. Actually, the first Saints Row had an infamously long and hard crunch period, worse than anything the studio had ever experienced. I started at the tail end of that, and I think it kind of traumatized everyone. For the first decade or so working there, I'd describe the attitude towards crunch as "we're never letting Saints Row happen ever again." The studio invested in more and better project management, experimented, and we're continuing to try and improve planning and cut earlier, specifically so we never crunch that hard ever, ever, ever again. Games are fun to work on, and their teams are fun to work with. Yes, it's a job, and it's common to have a very narrow view of what you're working on on any ordinary day-to-day work, and so that does take some of the "fun" out of it. Especially when you're dog-fooding on your own work. But I remember the internship positions I had doing "real jobs" before going into games, and they were B-O-R-I-N-G. I found my internships to be hideously awful, soul-crushing, "why-did-I-ever-think-programming-would-be-interesting-or-fun" affairs. Writing 100 or so trivial database queries over the course of a summer and then watching the resulting application for 8 hours/day to make sure processes are running is my literal definition of purgatory. And then there was the office politics... you know your internship is at a winning employer when your direct supervisor is suddenly fired, with two weeks left in your internship, and everything you've worked on all summer is completely forgotten and discarded, and you're told to still show up for work but to sit there and twiddle your thumbs until the end. And then there was the other internship, in which a senior programmer had an inexplicable grudge against me on Day 1, and wasted dozens of hours over the course of the summer trying to get me fired. The only reasons that was tolerable was my boss appreciated the schadenfreude when that senior programmer would accuse me of something new, only to be shown contradicting evidence and documentation. I thank the mighty Pastafarian noodleship that programmer was even more incompetent than they were malicious, because that paycheck was going towards my college tuition. I guess we all choose our demons, and I prefer being paid less to work harder on something I find interesting, alongside people I can actually like. Finding a silly bug, poking my office neighbor, and having a brief laugh and seeing if we can reproduce it. Playing board or card games over slightly-longer-than-usual lunches. I've become friends with a number of my coworkers - by which I mean more than just professionals working well together, these are folks I invited to my new place for a housewarming party, and that I've turned to when I needed help with a flooding basement, and that I've helped when moving across town. Folks I've gone drinking with, not just for team-building, but because they're great people to hang out with. Watching a project succeed is hugely satisfying After working hard to deliver a product, seeing it appear on store shelves - and then disappear from those shelves, with plastic markers indicating where it would be if only the store still had units in stock - is a remarkably cathartic experience. And reading positive reviews of the project is energizing. And even the negative reviews can be motivating, recognizing weakness in your own contributions and planning how to do better the next go-round. I think the proudest moment of my career was relatively early on, watching Red Faction: Guerrilla briefly bump up to a 9.0 metacritic score around launch time. I worked on its multiplayer, as part of a core team of 3 programmers and 1 designer. What I wouldn't give to relive those days, with just a few tweaks of benefit from a more experienced perspective.
  3. 2 points
    I've been working on a simple text editor for some time, and uploaded it to Github today. The editor is heavily inspired by GNU Nano, but not intended to have all its functions. It's just too much work in 65c02 assembly, at least for me At this moment basic editing works more or less, and the program is fairly stable. Text entered by the user is stored in banked RAM. File handling waits until the emulator supports reading and writing sequential files. Check it out on github https://github.com/stefan-b-jakobsson/x16-edit I also include the binary for my 0.0.1 release. It's tested in emulator version r37. x16edit-0.0.1.prg
  4. 2 points
    Neat, I hadn't realized MattGrandis was from the industry. Myself, I've been working at Deep Silver Volition, a modestly-sized studio in Champaign, IL, since 2006. So, close to 15 years in the industry. I have coworkers who have experienced every corner of the industry, from tiny indies who came looking for job security, to publishers like Activision and Ubisoft who have more artists working on flotsam like cola cans and dining props than Volition directly employs across the entire studio. About the industry in general Everything Matt said about the industry is absolutely true. I think the AAA side really hits its low point around the time of the infamous "ea_spouse" letter, which accused AAA mega-giant Electronic Arts of abusing their workforce with 70 hour work-weeks, as their modus operandi before talking about "crunch". EA was rumored to have 50% year-over-year turnover in their employees around that time, as in 50% of their workforce was leaving and needed to be replaced, each year. Crunch is still an infamous issue in the industry, whether we're talking about CD Projekt Red crunching to release Cyberpunk 2077, Ubisoft crunching to release Prince of Persia: Forgotten Sands, or Activision crunching to release the next Call of Duty, it's a practice that is endemic to the industry. To some extent, my understanding is that it's endemic to software development, but it's especially acute in gamedev. It's a complex problem to solve, and unionization would probably force the issue, but unions have their own problems and many gamedevs are understandably worried that if they attempted to unionize then they'd just get fired and replaced by younger, more naive kids. Job security is also still an issue today. Even the largest publishers are only 1 or 2 big flops away from ruin at any given time, and many studios don't functionally survive their first flop (they lose key employees, or are reorganized, or hemorrhage people until they can't operate, or simply shutter their doors forever), even if they have long histories of success. Also, it's still common for folks, artists especially, to finish a project and be immediately laid off because their studio won't have work for them to do for several months. Thankfully, Volition doesn't work like this, and never has, but my understanding is that we're an outlier. And yeah, in spite of some 27 years of being in business, we got hurt badly by the failure of Agents of Mayhem, our most recent release, which was just completely dead on arrival. This industry, I tell you. Saying "it's not for everyone" is a level of understatement I'd almost exclusively reserve for British characters from historical fiction. If V shutters, I'll probably exit the industry entirely, myself, go back to gamedev being a hobby that can exhaust my creative urges, and eventually reclaim the ~30% pay difference I'm told I could be making by plying my trade anywhere else in town. Oh, and that reminds me: Since nobody else has mentioned it, be aware that AAA gamedev absolutely comes with a fun tax, in that I mean you can expect to be paid less for what you're doing than if you were doing it for anyone else. Because getting in is grand, but there's no shortage of kids willing to absolutely kill themselves to get in behind you, and that drives down wages. (My story of breaking in out of college involved driving 5 hours to an in-person interview from out-of-state and booking my own room in a local motel. It really didn't bother me, in part because I didn't have any idea what to expect from the interview process; but since V tries to be better than most, our recruiter at the time was rather embarrassed by it. It helped drive my resume to the top of the pile, though.) Game-development options I also agree with Matt that, of those options, Godot is the closest to approach direct relevance for a game programming career, though you really want to look into Unreal if you're looking at a programming path. Failing that, at least C++. It's not that our industry has no need of low-level CPU and hardware guys, it's just that we're talking about a team of maybe 3 dedicated guys amongst a programming staff of 46, and it wouldn't even be that many except that we roll our own bespoke game engine for our franchises, instead of using a third-party engine. And besides, almost every platform is X86 these days... and have you seen that instruction set? Even in the heydays of Michael Abrash writing articles about VGA programming, optimizing that stuff was an art in trial and error, and these days really is best left to compilers. I would also echo Bruce's advice that you should probably think of your first game as a learning experience, and to decide whether you like gamedev enough to want to get in for the long haul. (Of course, if it turns out well, I don't think there's anything wrong with using it as a portfolio piece.) Whatever path you go, just remember these things: Keep it small. Keep it focused. Have fun! (Otherwise, what's the point?)
  5. 1 point
    I read the KERNEL-BASIC documentation and have not found a command to be able to position the text cursor (same as LOCATE in MS-Basic or HTAB and VTAB on the Apple ][). C64 BASIC solves this problem with the never-ending POKE hacks: June 1992 issue of COMPUTE Magazine, Gazette edition! (page G-24, "Programmer's Page" column) POKE 211,C (moves cursor to specified Column, 0-79) POKE 214,R (moves cursor to specified Row, 0-24) BUT you must PRINT a carriage return after that, or the ($D1) and ($F3) pointers won't be changed. So, that's why you must make: POKE 214,(R-1)AND255:PRINT:POKE 211,C Yuck!
  6. 1 point
    Where to start... I am an old school tech enthusiast (and modern too). Growing up on machines like the Commodore VIC20/C64, Texas Instruments TI-99/4A, and the Tandy Color Computers. While I love modern PC hardware, and have been building them since the 80386 era, I often miss the classic BASIC powered, command line driven, machines of the 1980's. I still play with many of them, via emulation on Windows and Raspberry Pi, but my wife and I simply don't have the space for me to keep a collection of the original hardware. Then I heard about the X16 project and who was all contributing to it, and I have been following it ever since. I normally don't have a lot of time to mess around on forums and such these days, but I wanted to join this one. If I could own one "classic" inspired machine, then the Commander X16 would be it. It seems like it would be the only machine of it's type that would fit my needs and wants of an 80's style computer today. Speaking of 80's computers, I got my first one in 1981, the TI-99/4A, and from there my love of these machines grew. I was lucky enough to either own, or got to use via friends, several different computers back in the 80's, including the Commodore VIC20 and C64, two of my all time favorites! I moved into the Amiga line of computers and Tandy 1000 series before moving completely to DOS/IBM PC machines. My least favorite machines of the era were the Tandy TRS-80 Color Computers, I know they are more commonly called "CoCo", but my friends and I back then called them "Trash 80's", we just never liked them compared to Commodore. They grew on me much later, after they were long since obsolete, and today I wish I had given them more of a chance. Now I use all modern Windows based, Ryzen powered, machines for myself and family. Doing a lot of emulation for classic computers and consoles for the above mentioned reasons. Most of my console emulation is done on Raspberry Pi, and classic computer emulation in Windows. I really enjoy using VICE, FS-UAE, WinUAE, DOSBox, and now I messing around with the X16 emulator of course! I think that's about it...
  7. 1 point
    I've written a tutorial a while ago on how to use BASIC to generate webpages, as how you would use PHP, it's almost useless but thought you guys'll want to see that https://toasters.rocks/esoteric-uses-of-cgi/
  8. 1 point
    This is subject to change as development of the kernel continues, but there are kernel variables for the screen size in characters: $386 has the width (llen), and $387 has the height (nlines). Maybe for pixels, you could just grab the HSCALE and VSCALE from the VERA configuration and calculate it ((PEEK($9F2A)/128)*640, (PEEK($9F2B)/128)*480).
  9. 1 point
    Then again, I have learned multiple programming languages for the express purpose of putting them on my resume. So, that may be a good start. Maybe not putting your actual game on your resume, but certainly your experience on using the language and engine it was written with.
  10. 1 point
    I'm looking at it from the front side, not after the fact. Going into the game with the goal of putting it on the resume is not the best mindset for the exploratory learning required. Indeed, going into it with the attitude that it's job interview material will, paradoxically, give a lower probability of it actually being effective as job interview material. After the game is finished, the advice has expired. At that time there's a game to look at to decide whether it merits being put on the CV.
  11. 1 point
    Far from everything ... to the extent that I am anything, I am a software hand, but I am just a dabbler taking a break from my day job. There are far better programmers than I am on this site. But early last year I did follow the experiments one fellow was doing with the Gameduino, before that design was dropped, and got a bit of a handle on how the linebuffer approach differs from the framebuffers we are so used to today.
  12. 1 point
    Edge cases are not useless: they're interesting.
  13. 1 point
    Lots of good advice in this thread, but I disagree with the idea above. Life's too short to pretend that some of your accomplishments don't matter. Maybe when you're on your 10th game, the first amateurish one won't matter so much. But until then, if what you make is good enough to release, then it's good enough to go on your CV.
  14. 1 point
    A good place to start would be to take a look here: https://github.com/commanderx16/x16-rom/blob/master/dos/README.md You could also take a look at this dos unit test here for some good examples: https://github.com/commanderx16/x16-rom/blob/master/test/dos.bas
  15. 1 point
    Aha, this is "prior window" and "next window" into the text buffer, with each window containing its own linking and text length information. Yes, the only relatively full featured editor I've ever written was a line buffer editor, so I fell into habitual assumptions. So to do an insert, you can look if the next window has enough space to store the text after the insert. If it does, slide its text up, copy the text in the next window into the space, and continue with the insert. If it doesn't, grab a new "empty" window and link it in, and copy the text after the insert point into the new window. You can go through and do small local memory collect at regular intervals, like when moving multiple windows up the chain, go back to the starting point and see how many windows is required to hold the first four buffers, and if its less than four, go through and compact them, releasing buffers from the "used" linked list and putting them in the "empty" linked list. Anytime on the 6502 that you go beyond a page, both complexity and size of code expands. With a page sized window, keep the address of the window we are at, CURRENT, in zero page and everything can be done with (zp),Y operations. For windows into a buffer stuffed with text, with each window containing two way linked list pointers and number of text characters, page size windows are ideal, the largest size buffer that allows all copies to be simple loops like: LDA SBNK: CMP DBNK: BNE + - LDA (SRC),Y : STA (DEST),Y, : DEY : BNE - -- LDA SBNK :+ STA BANK : LDA (SRC),Y : LDX DBNK : STX BANK : STA (DEST),Y : DEY : BNE -- One idea that reduces overhead by two bytes per page is have 64K buffers, in 8 consecutive High RAM segments. Then you keep a byte somewhere that has the bank of the first segment, you can use the high three bits of the LINK address to be the offset from the base. Then the link to page / bank converter, passing logical address in A and returning bank in A and page in X, is: LNK2PG: PHA : AND #%00011111 : ORA #$A0 : TAX : PLA : LSR : LSR : LSR : LSR : CLC : ADC BUFF0 : RTS There is an advantage to using an offset from a base bank even if you DON'T limit yourself to 64K files, because then you can have multiple BUFFERS, and the same operations can be directed to distinct buffers by just putting a different byte into BUFF0. But if you don't compact it, then "Link To Page" with the logical bank in A and logical page in X is just: LNK2PG: PHA : TXA : AND #$1F : ORA #$A0 : ORA #$A0 TAX : PLA CLC : ADC BUFF0 : RTS Even if you don't have an allocated use for the three redundant high bits in the logical page address, there's no harm in building in the ability to use them for some purpose later. For example, you might use them to indicate what KIND of text ... PETSCII, ASCII Latin-1, UTF-8 encoding of Unicode, etc. Having that encoded in logical address of each window makes it less likely that type of text information will be lost, and it makes sense to keep different types of text in different pages, even if there is free space available to merge them. _____________________________________________________________ Another way to reduce to three bytes overhead per page-window, while retaining the two byte logical address, is with an XOR double-linked list. In an XOR linked list, the "LINK ADDRESS" is the XOR of the LOGICAL ADDRESS OF "NEXT" and "PRIOR". I am going to assume for simplicity that the logical address is just the high byte of the page address with an assumed low byte of 0. If the above is desired, it still can be, with JSR LNK2PG at strategic intervals, but I'll set that aside. We store the ACTUAL ADDRESSES of PRIOR, CURRENT, and NEXT in memory in zero page vectors, since this lets us do "LDA (PRIOR),Y : STA ( CURRENT),Y" type operations with less setup. We also have PRBANK, CRBANK, NXBANK. To move UP the chain, we copy CURRENT to PRIOR and NEXT to CURRENT. And then for the physical address and the bank number of the new NEXT, we XOR the LINK in CURRENT with the ADDRESS stored in zero page. Note that you only access data in the CURRENT window, so whether the prior or next link is in the current bank doesn't matter. NEXTWIN: LDA CRBANK : STA PRBANK : LDA NXBANK : STA CRBANK : STA BANK L1: LDA PRBANK : EOR (CURRENT) : STA NXBANK L2: LDA CURRENT+1 : STA PRIOR+1 : LDA NEXT+1 : STA CURRENT+1 : STZ PRIOR : STZ CURRENT L3: LDY #1 : LDA PRIOR+1 : EOR (CURRENT),Y : STA NEXT+1 : STZ NEXT : RTS To move down the chain, we do the equivalent, swapping the role of PRIOR and NEXT. But to do local access to the current window, we don't need to worry about this. And to do local operations TO the next and prior windows, without moving our current spot in the chain, you still don't _____________________________________________________________ One reason I was writing a line oriented editor is that a line oriented system is very convenient for FORTH. The base address and number of characters can be handed directly to the interpreter, without any need to copy the lines. The idea this your approach inspires in me is to do something similar with 80 character line buffers, with the lower 5 bits of the logical page address being the page offset into the $A000 High RAM window, and the high three bits of the page address can be two bits to say which buffer INSIDE the page, 1, 2 or 3, and another bit is free for something else ... perhaps a dirty bit that is set when the line has been modified since the last save. BANK is 1 byte, the logical Window address is 1byte, with XOR linking only the two of them are needed, and the buffer plus the number of characters in the buffer is 81 bytes, so 83 bytes per window. AND ... 256/3=83.33333. For saving the file, the bank might by converted into the sequence of the bank that has been saved so far, so when loaded the banks are all relative to the start of the buffer, and it is easy to walk through the banks and convert them to their actual bank locations.
  16. 1 point
  17. 1 point
    You're welcome . The different backgrounds of people in this forum are indeed very refreshing and inspirational. And glad to help.
  18. 1 point
    Dual ported RAM is great, but these days pins seem to be more expensive than silicon, and dual ported RAM is really pricey for the amount of RAM you are looking at ... over US$2/KB. for 8Kx16bit, over $10/KB for 1Kx8bit. Of course, most of those are very fast RAM, so you are paying for speed as well as pins, but still ... pricey. They say the test of the pudding is in the eating ... as far as pins being more expensive than silicon, the least inexpensive dual ported RAM I see on the front page at Mouser ... ... is dual ported Serial RAM, so only 8 pins. ______________________________ Edit: I'll note another more reasonable dual ported RAM is 256 byte dual ported RAM with overlaid ADDRESS/DATA, so there is write address and read/write data modes (coded into two pins) plus eight A0/D0 ... A7/D7 pins, for 11 pins per port (including clock), plus power and ground. One interesting application for this is the Z80 UserPort box I was looking at ... you need a circuit to convert a Z80 read or write to the ADDRESS/DATA format, but the Z80 has wait state lines for both RAM and IO to make that a reasonable circuit to work out, and the UserPort could easily just bit bang the ADDRESS and DATA modes in PortB while connecting Port A to it's address/data port.
×
×
  • Create New...

Important Information

Please review our Terms of Use