It is currently Tue Dec 18, 2018 4:36 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3
Author Message
PostPosted: Mon Nov 02, 2015 10:35 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7027
Location: Canada
tepples wrote:
dougeff wrote:
I like to (in assembly) write to an unused bit of RAM just before and just after the action in question, and then run it in FCEUX with the debugger set to look for reads to that RAM address. It tells you how many cycles have passed between breaks.

So if the subroutine that you're trying to measure is run once or more per frame, how do you feed controller input to the emulated program between breaks?

There's actually two good ways I have used:
1. Use a gamepad for input and just hold it during the break.
2. Use FCEUX's TAS feature to play input for you. (Takes a bit of learning.)


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 11:47 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2356
Location: DIGDUG
Quote:
So if the subroutine that you're trying to measure is run once or more per frame, how do you feed controller input to the emulated program between breaks?


So far I've mostly used this to calculate how much Vblank time I have left, or how many cycles I have left before and after a Sprite 0 hit. You can set auto-button presses in FCEUX if you need, but it's tricky.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 5:24 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3410
Location: Richmond, Virginia
mikejmoffitt wrote:
Espozo wrote:
Some kid at my school actually typed a paragraph at over 120 WPM before. :shock: (I saw it.)

Some guy near my house actually drove on the road at over 60 MPH before. :shock: (I saw it.)

What, is typing at that speed not impressive? :oops:

rainwarrior wrote:
If you wrote the code last week, last month, five years ago, or someone else wrote it entirely, you've got your work cut out for you.

I guess that's why I write crazy long informative labels, (hence: "DMAPaletteRequestCounter") although it then comes down to speed, which at that point, it comes down to typing speed, so I guess it isn't totally irrelevant. :lol: I won't argue that C is faster though, I'm just not sure if it's speed to make outweighs the code it makes slowness, especially here. I don't know about you guys, but I just like being able to visualize exactly what the code makes the machine do and that what the machine is doing is all because of what I did, which I know is irrelevant, but it seems that not a lot of other people share this feeling.


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 11:33 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1765
Espozo wrote:
I don't know about you guys, but I just like being able to visualize exactly what the code makes the machine do and that what the machine is doing is all because of what I did, which I know is irrelevant, but it seems that not a lot of other people share this feeling.

It depends.

When I do low level stuff like writing to the PPU, I want to be able to control everything as well, that's why I always use Assembly in these cases.

But when I do mere mathematical stuff:
a = 3 * b + c / 2 - 1
or logical things:
if (x < 0 && e == 1) AddOpponent();
I don't really care about the underlying machine instructions.
As long as I don't suspect the compiler of having a bug and doing an incorrect calculation and as long as these instructions aren't a bottleneck in my code, why should I care how exactly the calculation is done?

Sure, on the NES it's a special issue since you really have limited CPU time, but I would never write anything in Assembly when I program a game on a PC.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 11:46 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3410
Location: Richmond, Virginia
I kind of mean that I have the satisfaction of knowing that what appears on the screen is completely my doing, not that some computer wrote something based on general commands I give it. I imagine many people here are here for the fact of actually making a game, and although I'm here for that too, I'm also here to have fun coding, and I feel like coding in a high level language would take some of the fun away. Sure, it's good for if you go to an office and have to write code all day as it's your job and you just want a paycheck, but it isn't something I'd want to do for fun. I'm also attempting to prove that something more technically impressive/better looking can be done on the SNES than what has been achieved, (if that's possible. It's recently been "discovered" that two of what are considered to be the most technically impressive games on the system only use SlowROM, so I'd say yes, and there's almost always room for improvement) because I feel that it's a system that has been shat on unfairly. Now, for the M92, that because I feel like it would be interesting to look at another processer architecture, and there's always the novelty of making an arcade game, especially on hardware Irem used.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 1:23 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
I understand the appeal of having done it all yourself, and having an in-depth understanding of the platform. I think everybody should work with some assembly at least on one project to get a stronger appreciation for how the computer works. However, with that sort of knowledge comes the power to more responsibly use a higher level language and understand the consequences of your code's design. For embedded platform development (of which all of these old consoles and arcade boards are examples), hardware-specific drivers can benefit from being written in assembly, while game logic and less hardware-specific things can afford to be written in something higher level. If you follow a design like that, you might find portability between two platforms (like, gosh, the SNES and Genesis!) with a simple driver rewrite and some design changes. Obviously it gets more complicated than that, but it means not rewriting all of your game logic.

I feel like your response about languages like C being good for office work is a little premature. It is great that you are enjoying learning assembly and system architecture at a young age, but coming to a conclusion like that comes off as a little over-reaching to me.

If you want a reference for some faith that a '90s arcade platform can run a game written in C, just about all of the Capcom fighters on CPS2 have a lot of their logic written in C (this is a mix of word-of-mouth, the fact that nearly perfectly-reproduced gameplay logic appears on multiple platforms (Alpha 3 on CPS2 --> Saturn --> Dreamcast --> PS2), and a hint of good ol' conjecture).

M2 wrote Fantasy Zone II DX for Sega System 16C in C, save for some graphics code that was done in 68000 assembly. The game runs great, and nothing obviously suffered as a result. Plus, the game received a perfect port to Nintendo 3DS. C came through as a portable language!

As poorly as Sonic Spinball runs on Sega Genesis, we must remember that the game was made in four months, and C compilers in the '90s were much harder to work with and had substantially less advanced optimization. Although the game was molasses on the Genesis, the use of C let the Game Boy Advance port used in Sega Smash Pack be a port, not a rewrite.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 1:46 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3410
Location: Richmond, Virginia
mikejmoffitt wrote:
If you follow a design like that, you might find portability between two platforms (like, gosh, the SNES and Genesis!)

I feel like on these systems that have their own strengths and advantages, it would be best to maybe make a similar game, but have it better based around the strengths of that system's hardware. I guess you could port a bulk of the code over though. I just see a lot of games on both systems being downgraded to be exactly the same on both, like ports across the Genesis and the SNES that only use about 64 colors on the SNES port, and may have 256 pixels wide in mind for the Genesis or use part of vram for sprites (you can try to dynamically switch it out to where it seems you have as much space as you could ever need, but that's a pain in the butt, as I can tell you...) when more can be used or whatever.

mikejmoffitt wrote:
I feel like your response about languages like C being good for office work is a little premature. It is great that you are enjoying learning assembly and system architecture at a young age, but coming to a conclusion like that comes off as a little over-reaching to me.

Yeah, sorry. I guess I meant to say that it's for getting whatever you want to get done, as if I were 100% focused on just making a game and could care less about actually programming it for the sake of programing it, then you'd go with C over assembly. At least, that's how it seems to me. I don't know if that's how other people feel.

mikejmoffitt wrote:
If you want a reference for some faith that a '90s arcade platform can run a game written in C, just about all of the Capcom fighters on CPS2 have a lot of their logic written in C

I don't think fighting games are particularly known for being processing intensive. What scares me is this... https://www.youtube.com/watch?v=lw8yq1ubQG0 And no, I don't hate Metal Slug. :roll: I think you already know what game I'm talking about now. :lol: (the 15fps 2D action game) I still can't fathom how having it screw up that bad is possible though.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 7:23 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
mikejmoffitt wrote:
M2 wrote Fantasy Zone II DX for Sega System 16C in C

And I'd assume that Konami also wrote II DX in C.

Quote:
Plus, the game received a perfect port to Nintendo 3DS.

The 3DS is also a shload faster. Each 68000 instruction outside drivers could probably have been translated to the equivalent C without much problem, letting the compiler's optimizer sort it out.

Quote:
As poorly as Sonic Spinball runs on Sega Genesis, we must remember that the game was made in four months

I made an NES platformer in assembly language in six months part time, doing all code but the audio myself, and it could have been four if the art was on time.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 9:52 am 
Offline

Joined: Sun Mar 27, 2011 10:49 am
Posts: 266
Location: Seattle
Espozo, I don't know if you're aware of this, but the main reason Metal Slug 2 is as slow as it is due to a very, very stupid bug.

Retro dev is where I get my assembly language fix - I find it really satisfying and fun. But my Master's is also in programming language theory, so I kind of take the dismissal of higher level languages as something of a personal affront. Not to sound condescending, your dynamic VRAM problem is basically a non-issue when using modern languages (not necessarily C) which have things like dynamic allocation, garbage collection, and hash tables built-in. But this doesn't make programming just busy work - on the contrary, it frees your mind to work on even more difficult, interesting problems. Programming languages aren't just means of expressing your thoughts but also tools that open up new ways to think, and - even if you enjoy ASM work - you're really doing yourself a disservice as a programmer if you close your mind off to them.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 10:01 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
Espozo wrote:
I feel like on these systems that have their own strengths and advantages, it would be best to maybe make a similar game, but have it better based around the strengths of that system's hardware. I guess you could port a bulk of the code over though. I just see a lot of games on both systems being downgraded to be exactly the same on both, like ports across the Genesis and the SNES that only use about 64 colors on the SNES port, and may have 256 pixels wide in mind for the Genesis or use part of vram for sprites (you can try to dynamically switch it out to where it seems you have as much space as you could ever need, but that's a pain in the butt, as I can tell you...) when more can be used or whatever.

Almost all of the time, those aren't codebase ports, and are more akin to remakes. Another World is an example of a port. The game runs in a VM designed by the game creator. By porting the VM to other platforms, the game is faithfully brought to other platforms. That's even more high level than writing a game in C.

Tepples wrote:
The 3DS is also a shload faster. Each 68000 instruction outside drivers could probably have been translated to the equivalent C without much problem, letting the compiler's optimizer sort it out.

"Translating" to C from 68000 assembly is not practical and would require lots of manual work to make truly portable code out of it. M2 has stated clearly the game is written in C. The point isn't performance, but that the game could be ported to a new native platform and be easily updated and modified along the way.


Tepples wrote:
I made an NES platformer in assembly language in six months part time, doing all code but the audio myself, and it could have been four if the art was on time.

That's not a fair comparison. Spinball is a larger game, and development now in any language is easier than development in the '90s in any language. Again, though, not the point - Spinball was ported to GameBoy Advance without a total rewrite because it was written in C.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 10:28 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11016
Location: Rio de Janeiro - Brazil
mikejmoffitt wrote:
"Translating" to C from 68000 assembly is not practical and would require lots of manual work to make truly portable code out of it.

I remember reading an article/interview saying that SEGA made a tool to perform this translation, so they could release Sonic CD (and S3&K?) for Windows. I have no idea how portable the resulting code was, probably not very.


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 10:48 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7027
Location: Canada
Espozo wrote:
What scares me is this... https://www.youtube.com/watch?v=lw8yq1ubQG0 And no, I don't hate Metal Slug. :roll: I think you already know what game I'm talking about now. :lol: (the 15fps 2D action game) I still can't fathom how having it screw up that bad is possible though.

It's a mistake to think that performance problems are simply caused by using C, or that they can simply be solved by using assembly.

Metal Slug 2 has performance problems because performance wasn't made a priority objective. It doesn't matter if you used C or assembly or whatever, you can ALWAYS create situations in the game capable of bringing your engine to its knees. Making a high performance game isn't just the compiler's job, it's the job of everyone on the team. Artists, designers, programmers, etc.

Management actually has to tell people "our game must run at 60fps wherever it can", and call out people to test the game and measure it, and fix problems as they occur (sometimes by changing code, but probably more often by changing level design).

If it's not a priority, management is more likely to say "no, don't work on that spot where it slows down, it's good enough. Work on --- instead." If, as a programmer, you were to abandon your task and start hand-optimizing stuff because you think performance is more important than what the people who are paying you told you to do.... you're not likely to keep your job long.

adam_smasher's link is very informative. That particular huge slowdown bug is not the result of using C or assembly directly, but the result of an error in logic made by the programmer. (You can make mistakes in any language.)


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 11:42 am 
Offline
User avatar

Joined: Sun May 27, 2012 8:43 pm
Posts: 1334
That is a big part of why Metal Slug 3 with Metal Slug 2's data structures results in a much better experience called Metal Slug X.

Tokumaru wrote:
I remember reading an article/interview saying that SEGA made a tool to perform this translation, so they could release Sonic CD (and S3&K?) for Windows. I have no idea how portable the resulting code was, probably not very.

That's interesting, I'd like to read about that. S3&K for Windows is a minimal emulator that triggers sound cues, though, not a translation.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 2 guests


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