Jump to content

Orab Games

Member
 View Profile  See their activity

  • Posts

    118

  • Joined

  • Last visited

  • Feedback

    0%

 Content Type 

Posts posted by Orab Games

    Badge Signup Thread

    in Archived Threads

    Posted · Edited by Orab Games

    Putting in a request for the following charms.

    Brewer, Graphic Artist, Publisher for Tailgate Party

    Brew Crew - Too many to remember. Many were KHAN's games.

    100+ Homebrews

    I'm close on music carts unless vinyls, casettes, and cds count, too? In the picture is 4 of @zi titles, 2A03 Puritans, Holly Jolly, A Winner Is You (cart, cd, cassette), Goofy Foot (cart and casette), and Creeping It Reel. Also have Project Blue and Alfonzo soundtracks on vinyl. Just throwing it out there in case it counts. EDIT: I guess I have a lot soundtracks on CDs I'm forgetting that can be seen in the picture. So, I'm guessing soundtracks aren't included.

     

    20210426_090256.jpg

    • Like 2
    • Love 1

    Tailgate Party

    in Share

    Posted

    32 minutes ago, Scrobins said:

    Also just want to say it’s great to see you here again @Orab Games! How have you been?

    Life has been pretty busy, but it's starting to slow down a bit. Excited to be doing something in the homebrew scene again. Very appreciative to k3vbot for keeping Tailgate Party alive while I had other duties to take care of. Maybe one day, I can get to working on another project. 🙂

    • Like 1

    VGS Homebrew Almanac

    in Share

    Posted

    38 minutes ago, the tall guy said:

     

    Does it really count as a likeness in an 8 bit game?  I mean, if it's some sprite that shares a first name with someone... just wondering how detailed it is or would have to be before it's literally like "look, that's me in the game!"

     

    Because if it was you in the game, you would be 32 pixels tall and the rest of the characters would be 16 pixels tall.

    • Haha 2

    VGS Homebrew Almanac

    in Share

    Posted

    2 minutes ago, Gloves said:

    Contracts don't have to be scary worrisome things, seriously. Consider a marriage contract, for instance. A contract is simply a statement of how each individual is going to be considered in the future when making decisions of any kind.

    Contract writing/signing time is your time to say "Actually I'd like to own the IP myself, and let you sell the game as part of your KS but not beyond that" and then if the other party disagrees you have that conversation. You know, BEFORE everybody has done a bunch of work on the thing, or even as is the case here, the work is done and has already been sold to people.

    There's nothing at all wrong with a contract, and if you ever present someone with the idea of drafting a contract together and they get antsy about it, that is your first RED FLAG! Seriously the stories of people being fucked in one way or another because of no signed contract, where they have no recourse at all, are plentiful. Do yourself AND your partner(s) a favor and always do a contract.

    For sure. I was working on a contract with an artist before I was forced to hang up programming as a hobby. To be honest, that person was very awesome to work with and I would recommend them to anyone for future projects! I feel terrible that I had to bow out right was we came to an agreement, but my life hasn't been the same since I had to make a choice to step away. Unfortunately, I doubt that project will ever see the light of day outside of concepts, but who knows. I'm forever grateful that they were understanding of my situation and understood that hobbies come after everything else in life.

    VGS Homebrew Almanac

    in Share

    Posted

    So, a couple things I see here.

    First off, I fail to see how these Kickstarter rules are not violated.

    • Projects that share things that already exist, or repackage a previously-created product, without adding anything new or aiming to iterate on the idea in any way.
    • Resale. All rewards must have been produced or designed by the project or one of its creators — no reselling things from elsewhere.

      Maybe there is a loophole being exploited with the book?

    Second, without legal contracts for publishing and IP ownership, I fail to see how Rob lost any of his rights to the game. He was not under legal contract, he was not an employee of Jeff's, nor has it been shown where Rob gave up any rights to the game, IP related to it, or branding which includes future titles or sequels. Mike Tyson can't create a "Mike Tyson's Punch Out 2" just because his name was on the game; just like I can't make a game using the Pac-Man sprite in a new game even if the entire game plays is changed. Without any of these legal documents or proper open licensing filed by Rob himself, the creator of the content is the owner of the content. I'm not a lawyer nor do I play one on TV, but I fail to see how Jeff can legally promote the creation of a sequel in a stretch goal without the original content creator's legal written permission. I don't see anywhere from either party where it explicitly says that Rob has given Jeff exclusive rights to all future creation, production, and publishing of all Black Box Challenge titles and related IPs, regardless of whose name precedes the title.

    It is very unfortunate that a fun collaboration project in a hobby community has come down to this, but I guess it shows that there may be something to contracts. I don't like operating on them, but to protect yourself and your creations, you have to now days. Hobbies aren't fun when legal matters get in the way. 😞

    • Like 2
    • Thanks 1

    Choosing a Tile Compression Method?

    in Programming Codebreakers

    Posted

    Yeah, there are many different ways to do it. But if you use someone else's compression tool (like shiru's), then you are bound by how they export the data. I do believe for values of 255 tiles in a row, they just do 255 and then start over with the same tile. So, if it was 275, you would write it 255 times and then do it again for 20 times.

    36 minutes ago, TylerBarnes said:

    This is actually might not be true, at least the way I'm picturing it.

    Again, this all depends on the exported code and how you program it. For some reason, this was sticking in my head for what I had to do. I'd have to check the code.

    Choosing a Tile Compression Method?

    in Programming Codebreakers

    Posted

    On 12/3/2019 at 6:44 PM, TylerBarnes said:

    For arguments sake, if RLE is the way I want to go is there a decompression routine that is standard?

    Here are the 2 common ways (in my short research form a couple years ago) that I saw RLE work for different tools. There are variations of this, but these were the basic concepts that I grasped. 

    ;First way: Using an indicator flag to tell your code when you are decompressing. Otherwise, just write the value
uncompressedBackgroundTable:
.db $11,$11,$11,$11,$11,$05,$07,$1f

decompressFlag  = $ff                ; You can't store tiles at $FF if you do this.
tileValues = $11,$05,$07,$1f
arrayLength = $05 

compressedBackgroundTable:
.db $ff,$11,$05,$07,$1f

    Here, you would write your code pointing at the compressedBackgroundTable to say if table value is $ff, then write tile $11 five times. Then write tiles $07 and $1f next. The result on the screen would look like the uncompressedBackgroundTable. You saved 3 bytes of storage in this example. Most RLEs using this format will just write single tiles and paired tiles to the screen without compression as it is faster and saves space. I forget how shiru's tool exports the tables for pairs. 

    ;Second way is not to use an indicator flag and always compress, even if it is 1 tile or a pair of tiles
;You would decide that if the first byte in the table is length or tile. In this example, I went length, tile.

uncompressedBackgroundTable:            ;Tiles on the screen
.db $11,$11,$11,$11,$11,$05,$07,$1f

compressedBackgroundTable:				;Same tiles compressed
.db $05,$11,$01,$05,$01,$07,$01,$1f

    Here, you would write your code to look at the first value in compressBackgroundTable and store the array length ($05). Then you would look at the second value to see what tile to write ($11). Then you would repeat until the end of the table. As you can see in this example, no bytes were really saved. The coding is much easier for this, but the compression can be worse depending on your screen. Busy screens could take up more data.

     

    Finally, you will have to write in your code some way to tell the system to exit the background writing loop. Since the table is compressed, the tables will be different lengths. You can figure out the best way for you, but I like to end my tables with a flag. In Example 1, I would use $FE as the last value in the table. If the code sees that value, it will exit the loop. However, now you can't store any tiles in $FE or $FF (well, technically you can if you use a third flag to ignore these 3 flags as flags). In the second example, you could just use $FF as the table ending flag. 

    ;From the first example, $fe tells the code to stop writing tiles.

compressedBackgroundTable:
.db $ff,$11,$05,$07,$1f,$fe

     

    Choosing a Tile Compression Method?

    in Programming Codebreakers

    Posted · Edited by Orab Games

    On 12/9/2019 at 12:40 AM, chromableedstudios said:

    I think shiru includes an asm RLE example with NES screen tool

    It does and I have used it. It works great with the proper decompress code. However, it's designed for tile by tile and not metatiles (that I know of, I haven't figured out any other way). I know plenty of programmers who just use RLE compression and call it a day. Some will write their own tools to compress metatiles with RLE as well, which can eat a lot of CPU time. From what i gather, you are trading CPU time for storage space with compression. With the advantages of homebrew mappers like GTROM and UNROM512, storage space is not much of an issue anymore unless your game is overly huge!

    If I were you, I would start with RLE and go from there. NESScreenTool does a great job. Do some research to understand how it works. For example, let's say that you have 2 tiles next to each other that are the same, the other tiles on either side are different. So, you have a pair ($03,$08,$08,$01). Some RLE compression tools will compress the $08 and others won't. It is actually faster to write the $08 twice than it is to uncompress it in some RLE tools. It simply comes down to how much more code do you want to write.

    Black Box Challenge

    in Share

    Posted

    15 minutes ago, Raftronaut said:

    I felt very very confused by the combat system in this game,  I got so frustrated on my first attempt that I set it down and never came back to it. Is there any sort of PDF manual or combat instructions available anywhere? I sure would like to give this game another shot...

    You have to go to the Dojo to learn about combat. Go to the 41:15 mark in this video.
     

     

×
×
  • Create New...