Homebrew visual novel
Moderator: Mask of Destiny
-
- Interested
- Posts: 14
- Joined: Thu Mar 21, 2013 8:33 pm
- Location: Hungary
Homebrew visual novel
Hello everybody!
As you can see, this is my first post and thread on this forum, i registered because i saw that the people here are helpful with development related questions, and tolerant for newbies too.
I started to like the Mega Drive long ago, but it was not my first or second console. I simply liked it because it was more mature than the SNES, and cheaper to collect for. Later i decided to try some programming, but i had no actual programming experience, so i tried many things to learn the most basics.
Getting to the point, i get an Eprom burner, test cartridges, memory chips, console exclusively for development, and a pc for programming. Now, i wanted to figure out what will be the easiest thing to make for this console, and it's the visual novel.
Next thing was the language, so beginning with the easiest method, i chose basic. Really, for somebody who knows next to nothing about programming it's not that bad or limiting.
The next thing was the theme, what will be my game about. Aaaand...don't hate me for this, it's MLP. No, i will not spread that here as a religion, i just liked the show, and saw the opportunity and ideas in it, with everything possible to make something original and good on it's own. Secondly, converting and making graphics for it is pretty easy, it doesn't need much color, and still looks good.
I finance the project, i program it basically from scratch by myself. I just want to create something nice, and not trash the Mega Drive with this girly stuff.
My girlfriend draws and recolors almost every graphics i need, and one of my friends compose the music for it, with Shiru's sound engine. I know it's unoptimized and quirky, but it does the job, works on real hardware, not mentioning the limitation wich made the music composer skilled on making MD tracks.
The game will be big, both story and size wise. I will fill the 32 megabit cartridge with content.
So far, i worked on this game for 7-8 months, developed small tools to convert text, made a VN engine for the game that i will hopefully use in a next possible game with improvements. If anybody is interested, i will post a proto rom and pictures.
Thank you if you read this wall 'o text.
As you can see, this is my first post and thread on this forum, i registered because i saw that the people here are helpful with development related questions, and tolerant for newbies too.
I started to like the Mega Drive long ago, but it was not my first or second console. I simply liked it because it was more mature than the SNES, and cheaper to collect for. Later i decided to try some programming, but i had no actual programming experience, so i tried many things to learn the most basics.
Getting to the point, i get an Eprom burner, test cartridges, memory chips, console exclusively for development, and a pc for programming. Now, i wanted to figure out what will be the easiest thing to make for this console, and it's the visual novel.
Next thing was the language, so beginning with the easiest method, i chose basic. Really, for somebody who knows next to nothing about programming it's not that bad or limiting.
The next thing was the theme, what will be my game about. Aaaand...don't hate me for this, it's MLP. No, i will not spread that here as a religion, i just liked the show, and saw the opportunity and ideas in it, with everything possible to make something original and good on it's own. Secondly, converting and making graphics for it is pretty easy, it doesn't need much color, and still looks good.
I finance the project, i program it basically from scratch by myself. I just want to create something nice, and not trash the Mega Drive with this girly stuff.
My girlfriend draws and recolors almost every graphics i need, and one of my friends compose the music for it, with Shiru's sound engine. I know it's unoptimized and quirky, but it does the job, works on real hardware, not mentioning the limitation wich made the music composer skilled on making MD tracks.
The game will be big, both story and size wise. I will fill the 32 megabit cartridge with content.
So far, i worked on this game for 7-8 months, developed small tools to convert text, made a VN engine for the game that i will hopefully use in a next possible game with improvements. If anybody is interested, i will post a proto rom and pictures.
Thank you if you read this wall 'o text.
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Hello and welcome!
The only problem with MLP, if I understood the acronym correctly, is copyright. The owners have already shut down a fighting game project. Any kind of serious project is at risk.
Of course you have to post stuff. That's the fun part!If anybody is interested, i will post a proto rom and pictures.
The only problem with MLP, if I understood the acronym correctly, is copyright. The owners have already shut down a fighting game project. Any kind of serious project is at risk.
-
- Interested
- Posts: 14
- Joined: Thu Mar 21, 2013 8:33 pm
- Location: Hungary
Here's a working copy of what it will look like.
There's no music, because the composer remade all of the old stuff, so i took them out. Because of this, the sound test is disabled, and turning on and off the music has no effect. This rom still has some errors here and there, but it works on Fusion and on a real PAL console. This took 7 months because i was lazy sometimes, and had real life problems, so the development was paused many times.
Please make suggestions and comments if this looks any good.
There's no music, because the composer remade all of the old stuff, so i took them out. Because of this, the sound test is disabled, and turning on and off the music has no effect. This rom still has some errors here and there, but it works on Fusion and on a real PAL console. This took 7 months because i was lazy sometimes, and had real life problems, so the development was paused many times.
Please make suggestions and comments if this looks any good.
-
- Interested
- Posts: 14
- Joined: Thu Mar 21, 2013 8:33 pm
- Location: Hungary
The problem is both actually, but since this is the only place where i gave out any information about my project, i don't think i will be harrassed for anything. I have my own directions and ideas for the game, which will be made for a long obsolete console.
And for a technical question: What happens to the MD's ram during a soft reset? For example, if i want to add a value for a memory adress each time i reset the console, will it be purged every time, or the memory will remain in the same state, and just the program starts from the beginning?
And for a technical question: What happens to the MD's ram during a soft reset? For example, if i want to add a value for a memory adress each time i reset the console, will it be purged every time, or the memory will remain in the same state, and just the program starts from the beginning?
-
- Very interested
- Posts: 2440
- Joined: Tue Dec 05, 2006 1:37 pm
- Location: Estonia, Rapla City
- Contact:
Nothing happens to RAM, it is up to you to clear it.
Mida sa loed ? Nagunii aru ei saa
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
http://www.tmeeco.eu
Files of all broken links and images of mine are found here : http://www.tmeeco.eu/FileDen
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
In sgdk, this is what happens to ram - from the sega.s file:
If you don't want some ram being cleared, you'll need to modify the clear ram routine to not clear an area, and then use that area for reset-proof data.
Code: Select all
* clear Genesis RAM
lea 0xff0000,%a0
moveq #0,%d0
move.w #0x3FFF,%d1
ClearRam:
move.l %d0,(%a0)+
dbra %d1,ClearRam
* copy initialized variables from ROM to Work RAM
lea _stext,%a0
lea 0xFF0000,%a1
move.l #_sdata,%d0
lsr.l #1,%d0
beq NoCopy
subq.w #1,%d0
CopyVar:
move.w (%a0)+,(%a1)+
dbra %d0,CopyVar
NoCopy:
-
- Interested
- Posts: 14
- Joined: Thu Mar 21, 2013 8:33 pm
- Location: Hungary
I don't really know if Basiegaxorz clears the ram after a reset, sadly i can't program right now anything in C or assembly. After this project, i will start to learn it to get out more juice from the console.
By the way, does somebody have some documents about the Codemasters J-cart hardware, like how to read or write the extra controller ports? I've searched for them, but found nothing. I have a plan to use a small microcontroller for some things later.
By the way, does somebody have some documents about the Codemasters J-cart hardware, like how to read or write the extra controller ports? I've searched for them, but found nothing. I have a plan to use a small microcontroller for some things later.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Oh, right. Forgot that... but by the same token, it bypasses setting the .data section with preset data as well, which kinda kills people on reset as nothing has the expected values. A proper startup should always copy .data and clear .bss. We should probably modify sega.s a bit to do that on reset, without clearing beyond .bss in ram.Stef wrote:In SGDK ram is only cleared on hard reset, not on soft one. If you look in the sega.s source, you will see that soft reset actually lead to bypass many init stuff and call _reset_entry instead of _start_entry in the sys.c base file.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
That is why you have a specific reset entry... reset stuff that you need to reset on soft reset. At contrary i think we should not reset static vars (and actually others memory parts too) on soft reset else you won't be able to distinguish soft reset from hard reset (i mean turn off and on) and keep some values in any way if you need to...Chilly Willy wrote:Oh, right. Forgot that... but by the same token, it bypasses setting the .data section with preset data as well, which kinda kills people on reset as nothing has the expected values. A proper startup should always copy .data and clear .bss. We should probably modify sega.s a bit to do that on reset, without clearing beyond .bss in ram.Stef wrote:In SGDK ram is only cleared on hard reset, not on soft one. If you look in the sega.s source, you will see that soft reset actually lead to bypass many init stuff and call _reset_entry instead of _start_entry in the sys.c base file.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
It's been part of every ABI forever that the way the program is on the first go-round is the way it is on EVERY go-round. Every OS that provides for reset proof memory have an API for allocating/locating said memory after reset. Even the N64 was this way, having a special (small) pool in the OS vars for reset proof memory.Stef wrote:That is why you have a specific reset entry... reset stuff that you need to reset on soft reset. At contrary i think we should not reset static vars (and actually others memory parts too) on soft reset else you won't be able to distinguish soft reset from hard reset (i mean turn off and on) and keep some values in any way if you need to...Chilly Willy wrote:Oh, right. Forgot that... but by the same token, it bypasses setting the .data section with preset data as well, which kinda kills people on reset as nothing has the expected values. A proper startup should always copy .data and clear .bss. We should probably modify sega.s a bit to do that on reset, without clearing beyond .bss in ram.Stef wrote:In SGDK ram is only cleared on hard reset, not on soft one. If you look in the sega.s source, you will see that soft reset actually lead to bypass many init stuff and call _reset_entry instead of _start_entry in the sys.c base file.
Once you have a way to setup/locate special blocks of reset proof ram, then you merely define a structure that specifies how variables are mapped to the block. That's easy enough for programmers.
As to how you tell it's cold or warm boot, you have a few ways... you can define an OS call that tells you if it's cold or warm (what N64 OS did). You can define special user functions that are called after a cold or warm boot (what the Amiga did). What most OSes do is leave it to the library that allocates reset-proof ram: if you try to LOCATE your block of reset-proof ram and the allocation fails, it's cold boot, duh. If you LOCATE the block just fine, it's warm boot. Once you know it's cold boot, ALLOCATE the block through the library. On warm boot, you LOCATE the block. In either case, you now have a pointer to a block of memory. Stick that in a struct pointer and you're good to go.
The reason ABIs do it that way is sheer effort: you only have ONE BLOCK to locate/allocate versus reseting the value of possibly THOUSANDS of regular variables. Which is easier?
I suggest one API call added to sgdk: palloc(int magic_cookie, int size);
That stands for protected allocation. You pass a magic cookie to use in recognizing the block and a size. The routine tries to locate the block first, and if it cannot find it, it allocates it and clears it. You can tell if it's cold or warm boot by defining a flag in the block - if the flag is clear, it's cold boot and the block was just allocated and cleared; you then set the flag along with any other default settings in the block. If the flag was set, you know it's warm boot and can rely on the rest of the block still having valid contents.
-
- Interested
- Posts: 14
- Joined: Thu Mar 21, 2013 8:33 pm
- Location: Hungary
Visual novel is very nice idea. Best will be to make Sega EBOOK file format and reader. Some kind of simple scripted text format with pictures and gamepad commands, plus buid in VGM music player. And maybe with WINDOWS/MAC/LINUX Sega EBOOK editor.
Something like simplified HTML script with just few commands...
Something like simplified HTML script with just few commands...
-
- Very interested
- Posts: 145
- Joined: Sun Jan 28, 2007 2:01 am
- Location: DCEvolution.net
- Contact: