Oddly

Hi guys, my names crest... I enjoy eating a detrimental amount of toothpaste... every day.

Actually here's an interesting video that I think is pretty moving about our educational system,

Dude, I almost failed every other class in highschool but could teach the computer courses... they literally called me back after I graduated to teach their robotics course.

Hey guys, found this really interesting article from the huffington post about the neuroscience of what is going on in a programmer's brain over time. http://www.huffingtonpost.com/chris-parnin/scientists-begin-looking-_b_4829981.html Really interesting read, highly recommend it.

Okay so basically, This is the quick run down of do's and don'ts for a GNU LGPL (Lesser General Public License) https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3) This basically says that if you take an open source application and modify it, the original writer of the software can not and will not be held liable for anything that happens with that code. Users who make modifications to a GNU LGPL Licensed code can commercially profit off of that application or code. With both the Lesser General public license (LGPL) , and the General Public License (GPL). The modifier of the code must: Source the origin of the code List any modifications the user made to that code Disclose their source ( Publish their code for up to 3 years ) GPL also states that anyone who edits your code, MUST release their code under the same GPL license. meaning, anyone who modifies your code, must also link back to their code of origin AND release open source as well. LGPL is actually more for the use of libraries though, so if you release a library, it is recommended to use LGPL. Where if the user modifies your library, they must release their modifications open source. However, if the user is simply using your library, they only have to link back to the source of origin. I recommend doing some personal research into how these licenses work. Edit: I 'll try to give an example ------------------------ I'm writing a customized emulator for gameboy where users can make roms multiplayer. I have multiple parts of this application each with their own licenses. In order to create games using my software, a user will have to link to one of my libraries. My library is sited as a different program than my emulator itself. My emulator is a GNU GPL licesned code, anyone who edits or customizes my emulator, must release their code open source under GNU GPL license as well. The Library that uses link to in order to make games on my emulator is released in GNU LGPL. This means, that any user who makes a game using my library, does not have to release their source code of they are simply using the library, they may also profit off of their game as they wish AND they may add their own license to their game. HOWEVER, if the user modifies my library in anyway, they MUST release that library under a GNU LGPL, and release their version of my library open source as well. --Both uses of the library will require the user/modifier to link back to my library in someway, or include it with their code.

If you guys want an article on any topics covering anything in software engineering, let me know, I'll make a post. So with engines, it's weird. Basically if he does GNU GPL, Any spin offs will be required to be open source. This would include games released with the software as well. He'd most likely have to choose LGPL, where the source code of spin offs may be closed, but the user must reference the source of the software either in the readme, or in visible text somewhere in their released product.

Hey all, I've been planning to release some edumacational guides to various importances of the wonderful world of software engineering. The catch to this tutorial, is I'm mildly intoxicated whilst writing it. In today's wonderful lesson, we cover Open Source Software. What does it mean? Open source software, as the name suggests, means that the source code is released with the application itself. This allows users of said application to come in and make adjustments to anything they'd like in the software, and in some cases, even redistribute the modified software. Let's hop into some details about using open source software. - USING - Open Source Software Obtaining: A lot of developers these days use various subversion repositories to release their code. A common source of open source repositories is, http://www.github.com/. I'm not going to go in too deep about how to use git, but I am going to go over two important keywords that you'll hear when referring to git and subversion repositories. Cloning: Exactly what it sounds like, when you close a repository, you copy all of its contents into your own source repository. This means you're ripping the code from the master source into a local source. Kinda like copying and pasting a file. Pulling: You can imagine a pull like a partial update, you're copying the changes in files from one source into your source. The reason I'm giving you these terms in this tutorial is because this is how features are implemented into open source software, this is also how users will often get updates to their code, - in the best way possible attempting to not break your change -. A lot of times with Open Source software these days, you're not going to be downloading zip files of code... unless you're eclipse and love the masochistic mindset of still living in the stone ages of online technologies.... LICENSING Oh my freaking glob this is so important and so commonly overlooked, seriously, read this.... Licensing is EXTREMELY important to both you and the releasing developer. Just because something is open source DOES NOT MEAN IT IS FREE GAME. A lot of the time when you're using open source software you'll see licenses included in the files. A couple common licenses you will find include: GNU LGPL (Lesser General Public License) GNU GPL (General Public License) MIT License IDGAF (I don't give a fuck License) If you do not know what each of these licenses are, and do not pay the time to review what licenses softwares are using, you should not be using that code or software. A simple extremely run down view (This is not all the licenses allow/do not allow): gnu LGPL: Code Modifiers must refer back to the original source of the software, commercial gain is allowed, modified software may be closed source. gnu GPL: Code modifiers MUST refer back to the original source, commercial gain is allowed, modified software MUST REMAIN OPEN SOURCE! (whether you're selling or not) ... For your benefit, here is a "too long didn't read" site on all the licenses, just search up the license you want, https://tldrlegal.com/license/gnu-lesser-general-public-license-v3-(lgpl-3) - RELEASING - Open Source Software Publishing As stated above, a lot of developers these days commonly release open source code to a repository. I HIGHLY recommend, if you're releasing code to release to github. Git is pretty easy to use once you get the hang of it. With releasing open source software, other people may also request edits to your code, and you can review them and pull them in as fixes to your software. Github has a lot of awesome interfaces for this. If you're not an advanced user and do not feel like learning how to use a git bash CLI, github also has a desktop GUI client. https://desktop.github.com with this you may manage your code from a GUI. I seriously recommend learning to use a command line for git, but that's your call. Another great feature about Subversion repositories is if a user of your open source code wishes to create a spin off of your program (basically modify it making their own changes and features), they may create their own branch of your repository. What this means is that a user can clone your project on github, that project will link back to your source/branch, and you will be granted a map to see everyone who has a branch of your code, see the changes they've made, merge their branches with yours, and they can pull code changes to your base branch into their sub branch. Cool right? Licensing As stated above, licensing is extremely important. More important to you, the publisher, than probably the user themselves. When creating a repository, github lets you choose what license to use. If you're cloning someone else's code and publishing it as your own, remember that their license still applies. for example, the GNU GPL license requires you to copy whatever license they're published under, AND you must refer to them as the license holder. In addition, you the publisher, will NOT be held responsible for any liabilities that occur to anyone who uses another code modifier's version of your software. That is extremely important. If you don't properly license your Open Source Code and someone modifies it to be a virus and uses it on others, the victim can potentially blame you. Without a proper license, you can take legal charges. - Conclusion- I'm surprised I typed this, holy shizz. Hope I learned you all a thing or two about open source software.

What is it? The Virtual Memory Bank Controller is a part of a special kind of Gameboy development kit I'm creating. As simply put, this part of the kit converts memory addresses from the Gameboy's 16-bit address system, to a 64-bit address system stored in the RaspberryPi (Or various other devices), (it also does exactly as the name suggests, it acts as a virtual memory bank controller to grab data based on how the gameboy requests it). Why did you make this? As there seems to be an increased interest in the trend of writing classic games with older technology, I have an interest in not only helping the trend develop, but expand upon it. This allows users to create their own custom cartridges to test their games on original systems with making any mods to the system themselves. With this, developers can insert instructions to any given part of the gameboy's ROM data and have the gameboy execute the instructions real time. This is also cool because it allows the gameboy to access features it originally never had, such as.. uhh... TCP sockets and online play. What further development is there? Currently, the system is capable of creating up to 2 virtual memory banks effeciently and convert addresses as it should, but some games require more than two banks, to continue development on this, i will next research how the gameboy instructs the cartridge's chips to swap Memory banks. In addition to this, I must also write a conversion system for the Raspberry Pi's GPIO pin data into two bytes, rather than the 16 bytes that represent the data already. After this, I plan to create a kit that simplifies the deployment of these games and allows communication with this device and a custom design emulator. Where can I find your project as is? std::cout << https://github.com/DylanDodds/gbComp << ", Right here" << std::endl; Information about the current state of the vMBC and why I'm releasing it now. I'm currently releasing the vMBC as a learning experience for anyone who is interested to learn how the Gameboy managed data. I will be updating a read me very soon to explain the system in organized detail. Currently the vMBC accepts a rom file, Spits out various information from the header data stored on the addresses $0000 - $01FF on the rom file (or cartridge), and allocates the necessary memory. It then splits that memory into it's designated rom banks and generates the designated SRAM banks, if necessary. When data is written to the SRAM banks, and the vMBC is closed successfully, any data in SRAM banks will be saved to a file. (This is how saving data will work on the system, instead of keeping it on RAM that is always on by a 3v battery) Libraries, Licenses, and Languages This software is written in C++, using (So far) only C++ standard and standard template libraries (STL). This software requires C++11 or higher. (std=c++11) The makefile included is built for the g++ compiler on debian linux, other operating systems not tested. License: GNU GPL v3.0 (GNU General Public License) https://github.com/DylanDodds/gbComp/blob/master/LICENSE And the cartridge? I'm waiting on my conductive copper tape to come in to expand the pins on the gameboy cartidge to get a proper solder job. After that, I will be releasing information on how to map this to a raspberry pi. I will be using a raspberry pi zero for this project. Screen Shot of debug information (to see something it's actually doing since most is background work) So the stuff under the -----------------------------Nintendo area that's the copyright logo that appears when you turn on a gameboy and the cartridge loads at the very begging when it says GAMEBOY. More to come as I get the online libraries linked in and the memory banks finished

This is not okay.

I love BBC.

Hex edit can be fun.

Then you do not hold the rights to sell the software. Edit: Also, I find it funny that you knew this and rather dodged the questions trying to sell it. A lot of us are pricks here but we know better than to try and scam eachother.

I pm'd him and still no reply. He dodged the information on engines/libraries usage.

PM'd

you gonna post them libraries and bases? or.... nah?

There is no way you wrote the graphics library. I'm sorry, but no one does anything on that low level for an indie engine. What did you use, SFML, XNA, What library do you use to call "DrawSprite" whatever? What Networking library are you using as well? What database software are you using and what libraries are you using to connect, write, and read from it. Did you write the engine from scratch, or did you use a base? What language is it in? This is important information you need to post before even selling stuff like this. People these days don't understand how licensing on software works, just because you can download and use a library does not mean it's free, and just because you write code using that library, does not make that code yours.

Im just gonna be the guy to say, since no one else has. I don't think this is that fancy, pokemon games and engines are over done. If you're gonna sell the engine, you can't legally sell it with the sprites and tiles and title it as a "pokemon engine" as it's trade marked. Edit: Also, before selling an engine, you need to review the licenses and legalities of all third party libraries you're using including the graphics engine and the networking libraries. Plus whatever code of whatever engine it's based on if any.

I'm curious to see what kinda of projects people got on the Githubs. Post a link to your profile. I'll even drop some follows or something. https://github.com/DylanDodds

This is how the vMBC Will work: First of all this is written in C++ where using Memory Pointers and Iterators is soooo convenient... The Raspberry Pi Zero has 40 GPIO Pins (or General purpose Input Output Pins), 25 of these pins are ACTUALLY mappable through C libraries (and a few other languages too) to set values to either High, or low. They can be both read from, and written to. These pins will be soldered to a few pins on the gameboy cartridge (After it is stripped of all its components). With these we can Read the Following Pins for the following information A0-A15, a 16bit memory address the gameboy will be using to access data from it's "chips" is retrieved from this. The gameboy has specific ranges in memory addresses for ROM data. As dummy data, we'll make believe that these address are between the 16bit hexidecimal addresses $C000 AND $DFFF. These 16bit addresses may be converted to int16_t variables in C++, or 16bit Integer variables, also called shorts in other languages. Now, the raspberry pi is a 64bit system and contains 64bit hexidecimal memory addresses, and obviously its memory addresses won't be constant and DEFINATELY won't use the same addresses as the gameboy, but that's okay, that's what iterators are for. If you don't know what an iterator is, this concept is basically: if I have an address, 164, and this is the start of an array of bytes, that 164 is only a pointer to the first byte. If I wanna get an 64bit (4byte) integer out of it, I have to get bytes 164, 165, 166, and 167 as well. Well iterators are simply 164 + 2 will get you the third byte in that array. It's kinda like simple mathematics with memory addresses. This is beneficial because we can calculate the offset of whatever memory the gameboy is trying to grab, and map it to wherever our memory is on the vMBC. Let's say we want to load ROM data into our system. We would have to take a ROM file and map it to the same RAM that the Gameboy is accessing from the vMBC. So to do this, we use a simple function in C known as a malloc. or Memory Allocate. This function (malloc(size_t size)) creates an array of reserved memory on our application's heap of whatever size we specify in its argument, The function also returns a void pointer to the first byte of our newly reserved date (which we can reinterpret as a char which is a plain old data type in C++ that is only one byte large. there is no byte object in C++). Now, we have the memory address and the reserved space, so we load all the binary data from (let's use a dummy rom file) SuperMarioLand.gb into our newly reserved memory space. So now, the first byte of memory from that gb file is the same as our char pointer object that malloc returned. We now have ROM data in RAM, with the address to that data, just as a gameboy would read it. Now let's address our problem defined earlier, mapping the gameboy's addresses to the Raspberry Pi's Addresses. So, as stated earlier in our dummy example data, our memory for our ROM on the Gameboy's address, which i will now refer to as a gbAddr, is between addresses $C000 AND $DFFF. In our system, let's say the first byte of the memory we Malloc'd earlier is addressed #00FF00EE in our Raspberry's pi RAM. This now means that the address $C000 in rom is #00FF00EE in the raspberry pi. Cool right? Well remember the iterators? Let's say our gameboy is trying to access the address $C020. We would calculate the offset where $C000 is equal to the 0th byte in ROM addesses. so $C020 - $C000 = 20. So that is the 20th byte in ROM data. Let's grab that from our RAM #00FF00EE + 20 = 20th byte from the loaded .gb in RAM. Now we return this value by writing to the D0-D7 where the gameboy's CPU will do whatever it needed to do with the requested data, such as load it into a register, add on it, whatever. This is how the Gameboy Computation Cartridge will work. Hope you learned something. For anyone interested in getting them edumatcations:

I've been talking a lot about assembly and C related stuff in the shoutbox this week and I'm sure at least 4 of you are curious. So, what the jazz am I doing. Well, I've seen A LOT of DIY Projects on people converting gameboy into rom emulators and stuff by replacing the guts of the raspberry pi, but my project... it's a little more interesting than that. Instead of replacing the guts of a gameboy to make an emulator, I'm using a Raspberry Pi Zero to create a Computation Cartridge that will work for GB, GBC, and GBA. This means, all of the original gameboy will be 100% intact, no modifications will be made to the system but the cartridge will allow the gameboy to do a lot of various tasks... Connect to wifi? Create a web browser rom for the gameboy? Gameboy Calculator, Internet Multiplayer play? (as in NetPlay, you can play with someone who is using a rom supported by NetPlay). You can also run low level operations on it to do various other applications, great tool for development and it will all be done via a gameboy cartridge. Now I know there are A LOT of limitations to this, for example how much memory addresses the gameboy can actually hold and how fast it can actually access that data. But I have a few theories to virtually expand the memory... So, without further-a-due, the post... So first thing was first, can I think of a way to make this possible? It starts with a lot of research... spent a good six hours just reading about how the gameboy works, found a good autopsy video on youtube explaining how the memory of the system worked, but I needed more in depth than that so I did some reasearch on a few sites. I needed to know how The pins worked and how the CPU talked to the cartridge. Got plenty of data on that, found out about the different chips on the cartridge and what memory addresses accessed the ROM and SRAM on a cartridge.... I had the idea, maybe I can replace the the rom chip without whatever output data i wanted from the pie so the CPU would just keep reading instructions as I entered them in... Problem was, there was more than just the ROM chip on the cartridge the accessed memory. There was also the SRAM chip, which managed various save datas, this chip is powered by the Infamous Coin Cell Battery that always dies when you make a pretty dope save and the games all "nah bruh, you can't have this"... figured that should go too, i have a storage location on the drive where I can load and save binary information to and from... |The other Issue was the ROM and SRAM were being controlled by another chip called the MBC or the Memory Bank Controller. Basically, this chip just said if the address is in this range, go to this bank in the ROM or SRAM and if the pin, SC was set to LOW (or 0), grab data from the SRAM... yeah that had to go, but it's function was ABSOLUTELY ESSENTIAL to the memory mapping features of the gameboy... so it was time to do some planning.... Eventually I came to find how the memory addresses worked in the Gameboy and how the addresses were being received, which is where I designed the above concept map. The Gameboy cartridge has 16 pins for a, you guessed it, 16-bit memory address. each pin representing one bit (translated in gbAsm (my short acronym for Gameboy Assembly Language) to Hexidecimal, yay) of the 16-bit address. These pins are referred to as A0-A15 pins. There are also a series of 8 pins next to these address pins referred to as D0-D7 pins. These pins are what memory you're reading/writing. 8pins = 8 bits, 8 bits = 1 byte. That's right, the game reads and writes instructions to and from ROM one byte at a time... lucky me... So what's all that hubba bubba from above? Well, that my friends is the software outline for a virtualized version of the MBC chip. I call it a vMBC for Virtual Memory Bank Controller, However it is commonly referred to as an MMU, or Memory Mangement Unit. Which will now be broken up into a separate reply. because I don't know if there's a post size limit.

ninety-seven