Visual Novel Engine

A place to discuss things that aren't specific to any one creator or game.
Forum rules
Ren'Py specific questions should be posted in the Ren'Py Questions and Annoucements forum, not here.
Message
Author
KOE
Regular
Posts: 44
Joined: Thu Aug 21, 2003 10:37 am
Location: Canada
Contact:

#31 Post by KOE » Wed Sep 03, 2003 7:28 am

Yeah, PNGs don't support multi-page images, but that's why MNG's were created.
And I agree, JPEG is the best format for BG's.

BlackSpider
Regular
Posts: 133
Joined: Fri Aug 22, 2003 1:08 pm
Location: Wroclaw, Poland
Contact:

#32 Post by BlackSpider » Fri Sep 05, 2003 11:03 am

I actually read a little about the MNG format. It looks interesting and could be used in future developement. I've already lost too much time implementing the IJG code in my own graphics library, and I'm affraid that including MNG support could be more difficult.

Although the IJG code is supposed to compile successfuly on any system, building the library for WATCOM C++ 11 was a real challenge. It appears that older versions of this compiler used different alignment fields for structures and there were some other incompatibilities too. Futhermore the IJG code only provided the file i/o data source, so there was the need to write a second data source manager that would read a compressed JPG file direclty from memory. I couldn't just let the player see all images before he/she actually started to play the game :-).

Then yesterday I had another idea. IMO there should also be a function (command) that could show backgrounds (or images) larger than the actual screen resolution. As an example let's take a cute girl's image at 640x(3*480) resolution. First the engine could show her legs, and then could slowly move upwards until the top of the image is reached. IMO this is pretty feasible, but as anything else requires time to make it work with a simpe single resolution engine.

KOE
Regular
Posts: 44
Joined: Thu Aug 21, 2003 10:37 am
Location: Canada
Contact:

#33 Post by KOE » Tue Sep 09, 2003 5:49 am

Yeah, the jpeg lib requires you to write your own source manager for memory decompression, but that takes about 20 so lines if I remember.
The bitmaps larger than screen resolution is basically like clipping the bitmap to the screen. Good idea.

BlackSpider
Regular
Posts: 133
Joined: Fri Aug 22, 2003 1:08 pm
Location: Wroclaw, Poland
Contact:

#34 Post by BlackSpider » Fri Sep 12, 2003 1:58 pm

Well, I think that so far all that could be implemented has already been discussed.

BTW, You could keep us updated from time to time on how your engine evolves :)

KOE
Regular
Posts: 44
Joined: Thu Aug 21, 2003 10:37 am
Location: Canada
Contact:

#35 Post by KOE » Mon Sep 15, 2003 9:55 am

Here's what the engine will be like:

The engine will be written in ANSI C. It will use SDL for it's low level media operations, and various other open source libs for other functionalities (jpeg, png, ogg, truetype, etc..).

The engine will interpret user written scripts (which will be C-like in syntax). These scripts will be used to control the flow of the game. Scripts can be interpreted at runtime (so users can modify the scripts easily) or as a compiled module.

For the first stage I'm developing a scripting engine library which allows programs to interpret user written scripts. This part only interprets script and does nothing more.

The second stage of the engine will be implementing a library of functions for the scripting library above. This library is basically the VN engine backend. For this part, I will place into the public domain (under GPL) and have anyone who wishes to contibute to the project.

Current status:
I have been able to parse scripts but have to implement the engine which interprets the scripts. Next task is to implement the engine, and perform vigourous bug testing. After this, I can proceed to stage 2.

BlackSpider
Regular
Posts: 133
Joined: Fri Aug 22, 2003 1:08 pm
Location: Wroclaw, Poland
Contact:

#36 Post by BlackSpider » Tue Sep 16, 2003 2:20 pm

So far, it looks great. I can only wish you good luck and hope that the project reaches it's final stage quickly :).

BTW like I already said, I'll be happy to help implementing stage 2. I may not be a pro, but I believe that I've already seen enough good code. I still need to learn to use SDL though :). It looks like it would be better to call this library instead of directly talking to the DirectX interface.

KOE
Regular
Posts: 44
Joined: Thu Aug 21, 2003 10:37 am
Location: Canada
Contact:

#37 Post by KOE » Wed Sep 17, 2003 6:49 am

Well, if you can program in DirectX, SDL is like nothing. It's got a simple to use API.. and all. I'll definatly let you know when I'm done part 1.

Eiji
Regular
Posts: 81
Joined: Mon Jul 21, 2003 3:32 pm
Location: Ohio, USA, Sector 001 Earth
Contact:

#38 Post by Eiji » Wed Sep 17, 2003 12:31 pm

SDL can also be used by that Korean game-deck... I think its called the "GamePark".. its not officially available in the states.. but you CAN import it and make games to sell with it.. and from what I seen it can support SDL library-powered engines.

though it does come with its own SDK too....

Naraku
Newbie
Posts: 20
Joined: Mon Nov 15, 2004 3:27 pm
Contact:

#39 Post by Naraku » Mon Nov 29, 2004 12:38 pm

Being a builder of computers I will say that the Celleron procesor
is a bad choice for a gameing machine because it often "hicups"
that is a timeing fault with the processor itself. When building with
cheap processors best to use AMD, I have only found a few
software incompatibilities and none were significant.
One important note when building around AMD processor
be sure to use AMD compatible video card.
If you have to use Intel processor, the biggest gain can be
had through a GPU video card (that is a video card that has
its own central processing unit and takes most of the load
off the computers main processor) try to get a video card
with 64MB or more of video memory, there is no shame in
opting for the cheaper PCI version as opposed to the
more expensive less compatable AGP.

User avatar
PyTom
Ren'Py Creator
Posts: 15437
Joined: Mon Feb 02, 2004 10:58 am
Completed: Moonlight Walks
Projects: Ren'Py
IRC Nick: renpytom
Github: renpytom
itch: renpytom
Location: Kings Park, NY
Contact:

#40 Post by PyTom » Mon Nov 29, 2004 2:04 pm

there is no shame in
opting for the cheaper PCI version as opposed to the
more expensive less compatable AGP.
I'm not so sure how true this is for visual-novel type games. In my experience profiling Ren'Py, the most expensive operation is moving images from the main memory to the screen. (Or blitting them around in main memory.) I would think the slowdown of PCI relative to AGP could be significant here.

Eiji
Regular
Posts: 81
Joined: Mon Jul 21, 2003 3:32 pm
Location: Ohio, USA, Sector 001 Earth
Contact:

#41 Post by Eiji » Tue Nov 30, 2004 10:50 am

Naraku wrote:Being a builder of computers I will say that the Celleron procesor is a bad choice for a gameing machine because it often "hicups"
that is a timeing fault with the processor itself. When building with cheap processors best to use AMD, I have only found a few software incompatibilities and none were significant.
One important note when building around AMD processor be sure to use AMD compatible video card. If you have to use Intel processor, the biggest gain can be had through a GPU video card (that is a video card that has its own central processing unit and takes most of the load off the computers main processor) try to get a video card with 64MB or more of video memory, there is no shame in opting for the cheaper PCI version as opposed to the more expensive less compatable AGP.
I prefer AMD processors too... they are just as much as the pentiums but they are more efficient and require a lot less clock speed...
"Who's the more foolish? the Fool? or the Fool who follows him?" -- Obi-Wan "Ben" Kenobi

"if you could tune into the fantasy life of a 9 year old girl, you can make a fortune in this buisness" -- George Lucas

Naraku
Newbie
Posts: 20
Joined: Mon Nov 15, 2004 3:27 pm
Contact:

#42 Post by Naraku » Wed Dec 01, 2004 10:32 am

In my experience profiling Ren'Py, the most expensive operation is moving images from the main memory to the screen. (Or blitting them around in main memory.) I would think the slowdown of PCI relative to AGP could be significant here.
With a GPU video card it makes no perceptible difference, most
modern video cards support drawing one screen while displaying
another and since the graphics processor handles transform and
lighting as well as DMA memory transfers that frees up the CPU
for other things such as game logic.

Post Reply

Who is online

Users browsing this forum: No registered users