It is currently Wed Sep 19, 2018 1:17 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
PostPosted: Sat Apr 14, 2018 2:50 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7517
Location: Chexbres, VD, Switzerland
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 ?


Top
 Profile  
 
PostPosted: Sat Apr 14, 2018 4:51 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1778
Location: Gothenburg, Sweden
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


Top
 Profile  
 
PostPosted: Sat Apr 14, 2018 5:29 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 659
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Ask the framebuffer of the library, feed it to the filter, blit the result yourself ...? Or such things aren't possible ?

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Sat Apr 14, 2018 6:42 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 4076
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!


Top
 Profile  
 
PostPosted: Sat Apr 14, 2018 10:44 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6805
Location: Canada
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.


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 1:47 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 359
NTSC to composite converter boxes cost $10, apparently. You could hook your computer up to a real CRT.


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 6:31 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20558
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 2:52 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 359
Oops, I meant to say VGA to composite, like you guessed.


Top
 Profile  
 
PostPosted: Sat Apr 21, 2018 5:55 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10806
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 8:21 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7517
Location: Chexbres, VD, Switzerland
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).

Quote:
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.

Quote:
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.


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 11:01 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6805
Location: Canada
Bregalad wrote:
Quote:
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:
Quote:
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.

Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 1:38 pm 
Offline
User avatar

Joined: Thu Aug 13, 2015 4:40 pm
Posts: 280
Location: Rio de Janeiro - Brazil
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!


Top
 Profile  
 
PostPosted: Sun Apr 22, 2018 8:53 pm 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3127
Location: Tampere, Finland
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


Top
 Profile  
 
PostPosted: Mon Apr 23, 2018 6:23 am 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20558
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Sun Apr 29, 2018 3:31 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7517
Location: Chexbres, VD, Switzerland
Quote:
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.

Quote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: adam_smasher and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group