Game prototyping environment that allows for NTSC filter

You can talk about almost anything that you want to on this board.

Moderator: Moderators

Post Reply
User avatar
Bregalad
Posts: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Game prototyping environment that allows for NTSC filter

Post by Bregalad » Sat Apr 14, 2018 2:50 am

I'm aiming to be able to code games in a high-level language (such as Python) in order to get faster development, (typically before the game is eventually converted to assembly and released on proper NES platform).

I was looking at the pygame library; the problem is that they use images directly to put on the screen. I still managed to code some sprite rendering routines so it's possible to do it manually but it's extremely slow and it'd be very hard to have an NTSC filter on this.

Is there an easy to use library where it's possible to code games and use a NTSC filter on top of it ?

User avatar
FrankenGraphics
Formerly WheelInventor
Posts: 2032
Joined: Thu Apr 14, 2016 2:55 am
Location: Gothenburg, Sweden
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by FrankenGraphics » Sat Apr 14, 2018 4:51 am

Game maker should work well enough for prototyping games. You can set up and blend frame buffers as much as you’d like. But it really depends on what you want to achieve. A perfect emulation of the whole NES featureset sounds cumbersome, for example. It should work well to test graphics and physics but that’s about it.
http://www.frankengraphics.com - personal NES blog

User avatar
TmEE
Posts: 712
Joined: Wed Feb 13, 2008 9:10 am
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by TmEE » Sat Apr 14, 2018 5:29 am

Ask the framebuffer of the library, feed it to the filter, blit the result yourself ...? Or such things aren't possible ?

User avatar
Dwedit
Posts: 4236
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by Dwedit » Sat Apr 14, 2018 6:42 am

If you really want to, you could write your game against Libretro, then run it in RetroArch. That would give you access to every feature of RetroArch without having to write it yourself.

I don't know if there are very high-level bindings for libretro though.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

User avatar
rainwarrior
Posts: 7675
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by rainwarrior » Sat Apr 14, 2018 10:44 am

A lot of modern game engines have some sort of option for a full screen post rendering shader effect. You can easily use an NTSC-simulation shader in one of those. Unity, Game Maker, Unreal, etc.

User avatar
pubby
Posts: 545
Joined: Thu Mar 31, 2016 11:15 am

Re: Game prototyping environment that allows for NTSC filter

Post by pubby » Sat Apr 21, 2018 1:47 am

NTSC to composite converter boxes cost $10, apparently. You could hook your computer up to a real CRT.

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by tepples » Sat Apr 21, 2018 6:31 am

NTSC is usually composite nowadays, except for the case of a cable box where the subscriber hasn't paid the high definition surcharge to Comcast. Did you mean VGA to composite, or HDMI to composite, or something else?

Besides, the shape of the artifacts depends on the number of color subcarrier cycles in a scanline. I think these scan converter boxes like the one depicted in my article use standard 227.5-cycle timing, compared to nonstandard 227.333-cycle timing used by the NES and Super NES and the different nonstandard 228-cycle timing used by the Apple II, Atari products, and Sega products.

User avatar
pubby
Posts: 545
Joined: Thu Mar 31, 2016 11:15 am

Re: Game prototyping environment that allows for NTSC filter

Post by pubby » Sat Apr 21, 2018 2:52 pm

Oops, I meant to say VGA to composite, like you guessed.

User avatar
tokumaru
Posts: 11466
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Game prototyping environment that allows for NTSC filter

Post by tokumaru » Sat Apr 21, 2018 5:55 pm

The output of a VGA-to-composite box looks very different from the output of authentic retro consoles. Not very for testing how graphics will actually look on the real thing.

User avatar
Bregalad
Posts: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Game prototyping environment that allows for NTSC filter

Post by Bregalad » Sun Apr 22, 2018 8:21 am

FrankenGraphics wrote:Game maker should work well enough for prototyping games. You can set up and blend frame buffers as much as you’d like. But it really depends on what you want to achieve. A perfect emulation of the whole NES featureset sounds cumbersome, for example.
I'll look into it. I'm not aiming at emulating the system perfectly, as look as it "looks the same" (including optional NTSC filter).
Ask the framebuffer of the library, feed it to the filter, blit the result yourself ...? Or such things aren't possible ?
It's possible, but apparently extremely slow. Currently I'm making my own frame-buffer and blitting it (not even with NTSC filter) but apparently you aren't supposed to do it like that, you're supposed to blit sprites directly which would be much faster.
If you really want to, you could write your game against Libretro, then run it in RetroArch. That would give you access to every feature of RetroArch without having to write it yourself.
I have no idea what this is but I'll look into it.

User avatar
rainwarrior
Posts: 7675
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by rainwarrior » Sun Apr 22, 2018 11:01 am

Bregalad wrote:
Ask the framebuffer of the library, feed it to the filter, blit the result yourself ...? Or such things aren't possible ?
It's possible, but apparently extremely slow. Currently I'm making my own frame-buffer and blitting it (not even with NTSC filter) but apparently you aren't supposed to do it like that, you're supposed to blit sprites directly which would be much faster.
Depends on the content of your game, but at low enough resolutions the advantage of using a GPU to composite tiles and sprites etc. might be very small, and there's a lot of flexibility in keeping it software-rendered instead. For something like NES resolution, I would probably only involve the GPU for the final stretch to fill the user's native screen (which is a perfect time for an NTSC filter too.)

The NTSC filter is probably ideally for the GPU, but an efficient software one like blargg's isn't that bad at all.
Bregalad wrote:
If you really want to, you could write your game against Libretro, then run it in RetroArch. That would give you access to every feature of RetroArch without having to write it yourself.
I have no idea what this is but I'll look into it.
RetroArch is an emulator framework that you get emulator plugins for. It handles the main interface, menus, the final screen compositing step (upscaling filters, including NTSC simulation), etc. so that all the emulators have the same front-end feel and you can switch between them easily. So the suggestion was that you could make a game as a DLL plugin for this.
Last edited by rainwarrior on Sun Apr 22, 2018 2:43 pm, edited 1 time in total.

User avatar
nesrocks
Posts: 434
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by nesrocks » Sun Apr 22, 2018 1:38 pm

It should be a fun exercise to implement reading and displaying of NES compatible CHR sets, nametables and palette files in gamemaker. It can read binary files just fine!
There's also a free chiptune plugin that plays back NSF files and there are screen shaders that you can use/program to simulate the NTSC filter.
It also already has a tileset environment to work on which you can set to 8x8.
As for palettes to work it would probably require writing an image buffer yourself (in gamemaker they are called surfaces).
The problem with gamemaker is that it isn't free, and the coding isn't centralized in one "main" function, meaning the order of execution between different objects isn't reliable inside each frame, so it takes a bit getting used to it.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!

User avatar
thefox
Posts: 3141
Joined: Mon Jan 03, 2005 10:36 am
Location: Tampere, Finland
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by thefox » Sun Apr 22, 2018 8:53 pm

It's a little bit "NIH," but personally I'd write my own (software) rendering code in C or C++ and expose an interface to the Python code. It's a bit more work to get set up but maximally flexible. Non-performance-critical parts I'd do straight in Python (e.g., window management and using OpenGL to display the framebuffer -- maybe just best to use something like PySDL2).
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi

tepples
Posts: 21751
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Game prototyping environment that allows for NTSC filter

Post by tepples » Mon Apr 23, 2018 6:23 am

One problem I recently ran into with PySDL2 is that it does not give the user a way to extract the contents of a surface to a byte string. Without that, I couldn't find a way to pass frames to FFmpeg when encoding a replay to video. From PySDL2 for Pygamers:
tostring(): No equivalent yet
The other is the fact that its sole official tutorial, to make a clone of Atari's Pong, is built around a strict component-oriented programming (COP) model that forbids an object to own more than one object of a given type, as the name of the field is literally the lowercased type name. This is Systems Hungarian taken to its illogical conclusion.

The Ren'Py project's pygame_sdl2 attempts source compatibility with Pygame, but its README notes the important lack of "APIs that expose pygame data as buffers or arrays." In addition, because indexed images are considered "legacy formats" unworthy of first-class support other than as a source for load-time conversion, there's no good way to palette-swap things at runtime without generating a separate 32bpp texture for each entry in the indexed image's palette.

That's why I stuck with the SDL 1.2-based Pygame for that project once Pygame had been updated for Python 3.

User avatar
Bregalad
Posts: 7766
Joined: Fri Nov 12, 2004 2:49 pm
Location: Chexbres, VD, Switzerland

Re: Game prototyping environment that allows for NTSC filter

Post by Bregalad » Sun Apr 29, 2018 3:31 am

RetroArch is an emulator framework that you get emulator plugins for. It handles the main interface, menus, the final screen compositing step (upscaling filters, including NTSC simulation), etc. so that all the emulators have the same front-end feel and you can switch between them easily. So the suggestion was that you could make a game as a DLL plugin for this.
While probably a good idea this souds extremely complicated. I've already sucessed (I think) at compiling .so files on linux, but I never managed to get .dll on Windows working fine with gcc.
It's a little bit "NIH," but personally I'd write my own (software) rendering code in C or C++ and expose an interface to the Python code.
Sounds like a decent option, too.

Post Reply